Отработав несколько лет в бекенд разработке, что, по сути, является конвертацией SQL в JSON и vice versa, ведением документации, писанием тестов и прочей рутиной – начал чувствовать выгорание (и это в 20 с небольшим). Благо, ситуация сложилась так, что на текущей работе пришлось повозиться с фронтендом, что меня затянуло и следующий проект я начал на Angular 2.
Сказка длилась недолго, окунувшись в мир фронтенд разработки 2017-года, я еще больше поник головою со всеми этими реактами, RN, vue, sass, webpack и прочими редаксами. Выполнив еще несколько проектов с уже все меньшей мотивацией, хотя и на интересных технологиях (Node.JS, GraphQL, Docker) понял, что на текущем месте работы больше психологически задерживаться не могу и сменил ее.
К несчастью (или к счастью), на новом месте не срослось (даже несмотря на хороший уровень зарплаты и коллектив из профессионалов) и я надолго не задержался. После увольнения взял пару месяцев отдохнуть, подумать.
Некоторое время мне довелось пожить заграницей и там часто пользовался популярным там сервисом для «митапов», но он всегда казался мне «тяжеловатым», хотелось чего-то попроще – вроде Tinder, но для повседневных занятий. Так я начал неспешно думать над написанием самого проекта.
Были следующие условия:
На первый взгляд, мой воображаемый проект идеально подходил под эти ограничения. Никакой работы с деньгами не требовалось, данных должно было быть по минимуму и бонусом – я был волен в выборе технологий. Бери и делай.
Будучи реалистом (а на спектре оптимист-пессимист скорее ко-второму), я здраво оценивал(-ю) шансы на «выстреливание» проекта в финансовом плане и всегда полагал стартапы как своего рода гемблинг. Дай бог из сотни выстрелит один, т.е. даст своему создателю финансовую независимость на N лет.
С тем же успехом можно поставить двухмесячную зарплату (примерно столько уйдет время на написание простенького MVP) на zero в рулетке и с шансом в 2.7% забыть о работе на 6 лет (при тех же тратах). На деле же, я не уверен, что выстреливает даже единичный стартап из сотен, что делает рулетку не такой уж и плохой альтернативой. (это, конечно, шутка)
С другой стороны, даже если проект не взлетит, то можно попилить его на части, выложить в open source, написать пару статей на Хабр, да и практический опыт никуда не денется – в конце концов, ваш почасовой рейт повысится и на дальней дистанции вы получите больше денег, чем ваши коллеги, спокойненько отсиживающиеся в офисе.
Не забываем, что работа над своим проектом летит куда приятнее, чем рутинное закрывание тасков в JIRA или Redmine.
Ну, наконец, самое интересное. Типичный современный веб-проект состоит из следующих частей:
Mobile. Тут для соло-девелопера выбор невелик, нейтив отпадает сразу, остаются кроссплатформенные решения. Я, имея уже опыт с RN, сделал выбор на Flutter, он еще сыроват, но пока (и если) я выйду в прод… В общем, выбор сделан, технология свежая, интересная.
Web. Тут я решил срезать углы и предоставить простой лендинг со ссылками на сторы, где можно скачать приложения.
Оркестрация контейнеров, кластер, отказоустойчивость, мониторинг, логирование. Без вариантов Kubernetes (вместе с Prometheus и прч.).
Docker Swarm мертв, а у k8s огромное community, легко-читаемый исходный код, куча инструментов. Работать с кластером, как минимум для мелкого проекта – одно удовольствие. Не последнюю роль сыграл доклад Д. Столярова по k8s.
Back-end. Имя за собой опыт спринга, использую его. Кроме того, какие-то отдельные высокопроизводительные сервисы (типа чата), хочу написать на Go. Все это будет плотно интегрироваться с нативными компонентами k8s (LB, service discovery).
В качестве инструмента CI/CD был выбрана Gitlab CI –там есть все – от тикетов и milestones, до интеграции с k8s и локального докер репозитория. Это будет ключевым инструментом на протяжении всей разработки.
Несмотря на наличие на проекте всего одного человека, не исключено подключения, например, фрилансера, поэтому для «новичка» должен быть обеспечен легкий вход.
Задачи раскиданы по milestones, прогресс актуализируется, в тасках есть необходимая информация. Все по взрослому. Да и самому приятно, виден как WIP (work in progress), так и выполненные таски.
Этот пост, разумеется, не единственный и не последний. В следующих записях будут описываться трудности, с которыми мне уже пришлось столкнуться по ходу реализации – материала накопилось на несколько постов – так и с тем, с чем еще придется.
Стоит добавить, что я сознательно не даю информацию ни по специфике приложения, ни по бизнес задачам, которое оно решает. Основная цель серии постов – ответить на вопрос – возможно ли написание современного 3-tier приложения с налаженным ci/cd силами одного посредственного [бекенд] программиста.
Чем ближе серия будет подходить к концу, тем больше будет даваться специфики по приложению, а в заключительном посте серии (если хватит «топлива» все закончить) – ссылки, скрины и итоги.
В ближайших постах – разберем великий и ужасный Kubernetes, а так же частично Gitlab CI.
Сказка длилась недолго, окунувшись в мир фронтенд разработки 2017-года, я еще больше поник головою со всеми этими реактами, RN, vue, sass, webpack и прочими редаксами. Выполнив еще несколько проектов с уже все меньшей мотивацией, хотя и на интересных технологиях (Node.JS, GraphQL, Docker) понял, что на текущем месте работы больше психологически задерживаться не могу и сменил ее.
К несчастью (или к счастью), на новом месте не срослось (даже несмотря на хороший уровень зарплаты и коллектив из профессионалов) и я надолго не задержался. После увольнения взял пару месяцев отдохнуть, подумать.
Размышления
Некоторое время мне довелось пожить заграницей и там часто пользовался популярным там сервисом для «митапов», но он всегда казался мне «тяжеловатым», хотелось чего-то попроще – вроде Tinder, но для повседневных занятий. Так я начал неспешно думать над написанием самого проекта.
Были следующие условия:
- никакой sensitive data
- никакой работы с платежными системами
- минимальные расходы на хостинг
- чтобы проект «самоочищался» и жил своей жизнью с минимальным вмешательством от меня
На первый взгляд, мой воображаемый проект идеально подходил под эти ограничения. Никакой работы с деньгами не требовалось, данных должно было быть по минимуму и бонусом – я был волен в выборе технологий. Бери и делай.
Будучи реалистом (а на спектре оптимист-пессимист скорее ко-второму), я здраво оценивал(-ю) шансы на «выстреливание» проекта в финансовом плане и всегда полагал стартапы как своего рода гемблинг. Дай бог из сотни выстрелит один, т.е. даст своему создателю финансовую независимость на N лет.
С тем же успехом можно поставить двухмесячную зарплату (примерно столько уйдет время на написание простенького MVP) на zero в рулетке и с шансом в 2.7% забыть о работе на 6 лет (при тех же тратах). На деле же, я не уверен, что выстреливает даже единичный стартап из сотен, что делает рулетку не такой уж и плохой альтернативой. (это, конечно, шутка)
С другой стороны, даже если проект не взлетит, то можно попилить его на части, выложить в open source, написать пару статей на Хабр, да и практический опыт никуда не денется – в конце концов, ваш почасовой рейт повысится и на дальней дистанции вы получите больше денег, чем ваши коллеги, спокойненько отсиживающиеся в офисе.
Не забываем, что работа над своим проектом летит куда приятнее, чем рутинное закрывание тасков в JIRA или Redmine.
Переходим к реализации
Ну, наконец, самое интересное. Типичный современный веб-проект состоит из следующих частей:
Mobile. Тут для соло-девелопера выбор невелик, нейтив отпадает сразу, остаются кроссплатформенные решения. Я, имея уже опыт с RN, сделал выбор на Flutter, он еще сыроват, но пока (и если) я выйду в прод… В общем, выбор сделан, технология свежая, интересная.
Web. Тут я решил срезать углы и предоставить простой лендинг со ссылками на сторы, где можно скачать приложения.
Оркестрация контейнеров, кластер, отказоустойчивость, мониторинг, логирование. Без вариантов Kubernetes (вместе с Prometheus и прч.).
Docker Swarm мертв, а у k8s огромное community, легко-читаемый исходный код, куча инструментов. Работать с кластером, как минимум для мелкого проекта – одно удовольствие. Не последнюю роль сыграл доклад Д. Столярова по k8s.
Back-end. Имя за собой опыт спринга, использую его. Кроме того, какие-то отдельные высокопроизводительные сервисы (типа чата), хочу написать на Go. Все это будет плотно интегрироваться с нативными компонентами k8s (LB, service discovery).
В качестве инструмента CI/CD был выбрана Gitlab CI –там есть все – от тикетов и milestones, до интеграции с k8s и локального докер репозитория. Это будет ключевым инструментом на протяжении всей разработки.
Несмотря на наличие на проекте всего одного человека, не исключено подключения, например, фрилансера, поэтому для «новичка» должен быть обеспечен легкий вход.
Задачи раскиданы по milestones, прогресс актуализируется, в тасках есть необходимая информация. Все по взрослому. Да и самому приятно, виден как WIP (work in progress), так и выполненные таски.
Будущее
Этот пост, разумеется, не единственный и не последний. В следующих записях будут описываться трудности, с которыми мне уже пришлось столкнуться по ходу реализации – материала накопилось на несколько постов – так и с тем, с чем еще придется.
Стоит добавить, что я сознательно не даю информацию ни по специфике приложения, ни по бизнес задачам, которое оно решает. Основная цель серии постов – ответить на вопрос – возможно ли написание современного 3-tier приложения с налаженным ci/cd силами одного посредственного [бекенд] программиста.
Чем ближе серия будет подходить к концу, тем больше будет даваться специфики по приложению, а в заключительном посте серии (если хватит «топлива» все закончить) – ссылки, скрины и итоги.
В ближайших постах – разберем великий и ужасный Kubernetes, а так же частично Gitlab CI.
Комментарии (8)
sentyaev
11.02.2019 13:43Вы сфокусировались на технологиях, а не бизнесе.
Выбросьте все, что вам не нужно и не имеет прямого отношения к бизнесу.
Mobile. Тут для соло-девелопера выбор невелик, нейтив отпадает сразу, остаются кроссплатформенные решения. Я, имея уже опыт с RN, сделал выбор на Flutter, он еще сыроват, но пока (и если) я выйду в прод… В общем, выбор сделан, технология свежая, интересная.
Если у вас есть опыт в мобильной разработке, пишите для одной платформы, если взлетит портировать будет не особо сложно.
Web. Тут я решил срезать углы и предоставить простой лендинг со ссылками на сторы, где можно скачать приложения.
Сверстать страничку на wix или wordpress будет достаточно.
Оркестрация контейнеров, кластер, отказоустойчивость, мониторинг, логирование. Без вариантов Kubernetes (вместе с Prometheus и прч.).
Выбросьте эту идею, вам это понадобится… хотя для такого проекта никогда не понадобится. Простите за категоричность, я конечно могу не знать ваших планов.
Back-end. Имя за собой опыт спринга, использую его. Кроме того, какие-то отдельные высокопроизводительные сервисы (типа чата), хочу написать на Go. Все это будет плотно интегрироваться с нативными компонентами k8s (LB, service discovery).
Знаете спринг, пишите на спринге. Все остальное подключайте готовое, например чат, есть куча готовых решений которые не только сам сервис делают, но и компоненты для мобильных приложений, и это касается всего, почта, оплата, авторизация, очереди, базы данных.
В качестве инструмента CI/CD был выбрана Gitlab CI –там есть все – от тикетов и milestones, до интеграции с k8s и локального докер репозитория. Это будет ключевым инструментом на протяжении всей разработки.
Выбросьте этот шаг тоже, как закончите MVP так и прикручивайте, а то этого момента не тратьте свое драгоценное время, которое, уверен, не так то и просто найти.
Задачи раскиданы по milestones, прогресс актуализируется, в тасках есть необходимая информация. Все по взрослому. Да и самому приятно, виден как WIP (work in progress), так и выполненные таски.
Сделайте табличку в Excel, вам этого на первый год точно хватит.
Akuma
11.02.2019 14:32+4Как владелец своего проекта полностью соглашусь со всем вышесказанным.
Точно так же совершил кучу ошибок типа «буду использовать эту технологию, потому что это круто». Нафиг. Использовать надо то, с чем умеешь работать и то, что умеет экономить время.
Gitlab мне понадобился спустя почти год развития. Причем никаких milestones так и не использую. Исключительно хранение кода + CI/CD да и то для сборки в условиях плохого интернета, раньше вообще локально все собиралось.
Закрывать таски приятно только когда сидишь на зарплате. Когда пилишь свой проект тасков будет столько, что закрывать их будет некогда.
Как оказалось развитие своего проекта — это далеко не один лишь кодинг.
springme Автор
11.02.2019 14:53-4буду использовать эту технологию, потому что это круто
Я их использую с прицелом на будущее использование в работе, на которой платят.
Я увидел тренд k8s и решил запрыгнуть в него таким образом – через написание своего проекта. Так как текущий рынок труда дает мне на выбор – продолжать работать Spring Developer (а там я уже выгорел), либо (чтобы поработать с k8s) менять квалификацию в devops. Я ни хочу ни того ни другого.
shpaker
11.02.2019 17:16+2у k8s огромное community, легко-читаемый исходный код, куча инструментов. Работать с кластером, как минимум для мелкого проекта – одно удовольствие.
Ну такое… У нас с вами видимо какой-то опыт столкновения с этим продуктом очень разный.
springme Автор
11.02.2019 14:48-3Вы сфокусировались на технологиях, а не бизнесе.
Выбросьте все, что вам не нужно и не имеет прямого отношения к бизнесу.
Как я писал в статье – «профитность» проекта это не первоочередная цель и зависит от многих факторов, в том числе и от удачи. Я не хочу писать на вордпресе потому что мне не интересно, я хочу верстать на градах потому что мне интересно, даже ценой «лишнего» времени.
Если у вас есть опыт в мобильной разработке, пишите для одной платформы, если взлетит портировать будет не особо сложно.
У меня нет опыта нативной разработки, поэтому, при беглом анализе, я выбрал кроссплатформенный флаттер – уже пробую и уже нравится. После моего основного языка – Kotlin – с Dart вообще проблем не имею.
Сверстать страничку на wix или wordpress будет достаточно.
Страничка это вообще ерунда, ее можно сверстать на чем угодно.
Выбросьте эту идею, вам это понадобится… хотя для такого проекта никогда не понадобится. Простите за категоричность, я конечно могу не знать ваших планов.
Вы правы, но все затевалось именно для изучения k8s. Поэтому он и Gitlab CI – два столпа всего проекта.
Знаете спринг, пишите на спринге. Все остальное подключайте готовое, например чат, есть куча готовых решений которые не только сам сервис делают, но и компоненты для мобильных приложений, и это касается всего, почта, оплата, авторизация, очереди, базы данных.
Разумеется я не буду ничего писать с нуля.
Выбросьте этот шаг тоже, как закончите MVP так и прикручивайте, а то этого момента не тратьте свое драгоценное время, которое, уверен, не так то и просто найти.
Это уже помогло отделить зерна от плевел и определить функционал MVP.
Сделайте табличку в Excel, вам этого на первый год точно хватит.
Нет, Excel я не люблю, да и зачем, если гитлаб поднимается за 5 минут?
Я уже не говорю о том, что подключать разработчиков или фрилансеров в последствии будет куда проще в гитлаб, нежели в «страничку в Excel».sentyaev
11.02.2019 16:39Как я писал в статье – «профитность» проекта это не первоочередная цель
…
все затевалось именно для изучения k8s
…
подключать разработчиков или фрилансеров в последствии будет куда проще
Звучит как: денег не будет, работа ради процесса, а не результата. Не очень это вяжется с привлечением дополнительных людей.
Я не хочу писать на вордпресе потому что мне не интересно
…
Нет, Excel я не люблю
Это инструменты, не важно нравятся они или нет, важно позволяют-ли они решить задачу быстрее/дешевле, лекго ли найти людей которые ими ползуются, можно ли получить поддержку и т.д.
В любом случае желаю успехов.
Главное выберите правильную цель, неважно какую — бизнес, обучение, еще что либо, и сфокусируйтесь именно на одной цели, не распыляйте силы.
За десятерых работать можно, но не долго.
deniskin
Невозможно написать стартап. Это же не только программный код, это и другая работа. Стартапы не пишут, ну разве что теоритизируют в виде ТЗ или проверки гипотез. Стартапы создают, и эта работа гораздо обширнее, чем просто написание кода.
springme Автор
Я долго думал над названием, определение слова «стартап» слишком расплывчато, я сменил в заголовке на «проект». В остальном вы правы, моя вина, что не изложил в статье верно.