Comments 40
Что за пед проекты? )
"Казаки изъяли тесты Роршаха, содержавшие порнографию" (С)
Если правда не знаете - это он английского pet, питомец. Что-то вроде личных проектов для души, а не для бездушного бизнеса
Писал много лет код, настраивал VPN, верстал адаптивную верстку,
вваливал в Директ сотни тыщ рублей и в итоге остался со своим красивым
кодом и проектом, который не то, что не окупается, а является убыточным и
как камень на шее: убить жалко, а продолжать пилить нет мотиваци.
Надо было сначала прощупать как-нибудь, наверное, нужен ли ваш проект вообще кому-либо кроме вас, чтобы не слишком много лет в пустую потратить... Но тут и я не особо эксперт, на самом деле
Чаще всего собственный pet-проект это возможность попробовать новые технологии, библиотеки.. все то что не будет одобрено на работе (или просто от желания попробовать себя в другой области) и при этом он какое-то время делает что-то нужное тебе. Да возможно с 99% вероятностью!!! в какой-то момент времени он станет обузой, но в большинстве случаев это означает, что вы не смогли, или не стали формировать вокруг него сообщество. Просто нужно помнить, что вы делали это just4fun и не накручивать себя.
Кстати, за успешными примерами далеко ходить не надо, например ueviever от gildor, весьма успешный в узких кругах мододелов проект хоть и вялотекущий, на сколько я знаю владелец какое-то время работал на nvidia. Или Steve Streeting который известен как создатель ogre3d и sourceTree, последний кстати в итоге неплохо был монетизирован в 2011.
Никогда не надо делать первой целью монетизацию проекта. Пет-проект должен быть инвестицией всегда и в первую очередь должен делаться для развития навыков, а также если вам действительно интересно создать что-то новое. Монетизация - дело вторичное и хорошо, конечно, если проект получится монетизировать, но если не получится, вы всё равно будете в выигрыше.
Доход с пет-проекта может быть показателем его субъективной полезности (раз люди готовы даже за него отдать деньги!), а навыки разработчика создавать реально нужный для рынка продукт/проект - ещё дороже будут цениться в работе.
Так что я категорически не согласен, что:
Никогда не надо делать первой целью монетизацию проекта.
Разработчики тоже не в вакууме существуют, а на рынке, поэтому умение зарабатывать деньги эффективно не только компании, но и себе (даже если вдруг уволят или ещё что-то) - это один из полезнейших навыков.
Тут вопрос в другом совсем. Конечно же хорошо заработать на своём проекте деньги, кто спорит.
Но есть другая проблема - разочарование, если цель не будет достигнута.
Как мне кажется намного лучше иметь другие цели как первостепенные (а именно - инвестиция в себя, развитие навыков, да и просто создание интересного продукта как минимум для себя). Эти цели 100% достижимы и в них вы не будете разочарованы. И уже после того, как первые цели достигнуты, можно переходить к следующей - монетизации.
Я считаю , что намного больше шансов достигнуть вторую цель (монетизацию проекта), если у вас также есть и другие цели (о которых я писал). А на одной монетизации будет сложно уехать, легко будет сорваться и перестать этим заниматься. Всё равно, что работать на нелюбимой работе с единственной разницей, что денег вы за это не получите, по крайней мере в ближайшее время.
а за что человеку минуса ляпаете? я вот прекрасно понимаю как переводится PET, но абсолютно не в курсе что такое Pet-проект. Собственно в эту статью и зашёл чтобы об этом прочитать, но никто не додумался написать разъяснение.
хм.... а вторая команда "типа стартап" - это потому что у них тестировщиков нет ? :D
команды будут разрабатывать место в интернете, где специалисты смогут объединяться и делать проекты
Соревнование "Кто быстрей напишет трекер+вики+гит"?
Интересно, почему решили начать сразу с микросервисной архитектуры?
За свою команду могу сказать, что нам проще и быстрее разделить сложную логику на маленькие части. Предполагаю, что так нам будет намного проще писать и даже если где-то будет заведомо плохая архитектура - она не будет распространятся дальше, как это могло бы быть в монолите
Разделение логики на части понятно, но при разнесении этих части в отдельные сервисы, взаимодействующие по сети, появляется дополнительный пласт работ по развёртыванию, мониторингу, авторизации, обеспечению отказоустойчивости, которые в рамках MVP кажутся лишними.
Про архитектуру не совсем понятно, ничего же не мешает разделить всё на модули (каждый со своей архитектурой, если необходимо).
PS На последнем Хайлоаде был прикольный доклад на эту тему https://highload.ru/spb/2023/abstracts/10442 (смотреть за деньги, но там есть бесплатная презентация)
Стажеры\джуны любят перевязывать слои\компоненты между собой при реализации задач. Микросервисная архитектура помогает жестко отделить доменные контексты и обеспечивать low coupling high cohesion как внутри сервисов, так и во взаимодействии между ними. Думаю это главный поинт в пользу этого решения.
Понятное дело, что мы нагружаем себя доп. работой по части деплоя и обеспечения межсервисного взаимодействия, но код получится более сепарированным и более легко поддерживаемым.
К тому же, если вы посмотрите первичную реализацию сервиса у красной команды - это монолит, со спрятанной внутри микросервисной архитектурой. Проблемы с деплоем минимальные, общаться между сервисами можно в памяти, low coupling high cohesion соблюдается. Когда дорастем до продакшена (если успеем вообще за время ведения проекта) - разделим монолит на микросервисы по щелчку пальца, если в этом будет потребность.
Потому что за ними будущее. А делать проект на легаси подходах - не вижу в этом никакой ценности. Да и по итогу, наши бэкендеры всё-таки решили не делать микросервисы)
Главный приз — стажировка в IT-компании
Новые времена - новые призы. Когда уже будут голодные игры за стажировку?
Я правильно же понял - в синей команде 3 дизайнера, 3 бэка, 3 фронта и 3 тестировщика? На один продукт? Ставлю на красную тогда. А если была бы еще зеленая из одного фронта, одного бэка и одного дизайнера, то поставил бы на неё )
Кстати, а им надо только сделать продукт, или еще развернуть и поддерживать?
Не поленился чекнуть участников (потратил 15 минут своего времени))) и я понять не могу вот чего... "С 25 сентября и на протяжении двух месяцев команды начинающих IT-специалистов будут работать над пет-проектом" - И получается что у вас в двух тимах есть ребята уже с портфолио т.е они уже что-то делали, там у одного парня вообще 2 года коммерции, эт он че, работу так и не нашел? Есть конечно и ребята, которые прям "начинающие", но...
И приз еще "Стажировка в ИТ компании"...
В любом случае пожелаю удачи командам.
Некоторые хотят сменить профиль деятельности, некоторые хотят получить опыт командного взаимодействия в определенных условиях, цели у участников проекта самые разные, но в целом все из них "начинающие".
В текущих реалиях на стажера 2 года опыта надо судя по всему)
Так это ж не хакатон какой, а зрелище. Да и на хакатонах в первых рядах сильные специалисты, а начинающие собирают дипломы участников. Или слабые нередко имеют в своих рядах незарегистрированного сильного, если какие-то ограничения на состав... Впрочем, не о том речь.
А вообще тут неплохо -- сильный в случае чего и подскажет, и научит. Вытянуть всё в одиночку вряд ли сможет, но задать темп и вовремя направить -- вполне, чтобы не было праздного шатания молодняка. Стажировка ему вряд ли сдалась, а вот покрасоваться перед потенциальным работодателем, получить новый опыт и красивую запись в резюме уже интереснее.
Короче, ничего плохого. И да, удачи командам!
Возможно, очередной конкурс для «своих». У этого проекта даже анонса на отбор не было.
Ну почему же? Анонсы были в наших соцсетках (вот такой пример).
Подписан в твиттере и тут. Ни там, ни тут анонсов не заметил.
Вот еще пример...
"где можно объединяться с единомышленниками и работать над IT-продуктами" гитхаб что-ли?)
В левой команде 2 дизайнера, 2 бекендера и 1 фронт - тяжело ему будет...
Я фулстек - и по моему опыту на 1 час бекенд разработки - приходится 2-3 часа фронта.
ПМов не надо АХАХХАХА
Вообще пэт-проекты нужны по трём причинам.
1) Попробовать что-то с чем вряд ли придётся иметь дело на работе, но очень интересно как это будет работать, выглядеть, функционировать.
2) Показать на примере пэт-проекта, что ты можешь и умеешь, так сказать, не на словах, а на деле, и не надо доказывать свой опыт и способности, если бы не умел, не сделал бы. Так что просто сделайте пэт-проект, чтобы показать на собеседовании или работодателю, это вместо 1000 слов подтвердит, что вы можете и умеете это делать.
3) Если умеешь программировать, почему бы не сделать пэт-проект для себя, чтобы он помогал в твоих делах, а потом вжух, и это вдруг станет нужным и полезным ещё для кого-то, и так пэт-проект стал не только помогать, но и приносить прибыль.
Делать большие ставки на пэт-проекты не стоит, однако, если вы делаете это осмысленно, а не из серии "крудошлёпство", "ещё один сайт на вордпрессе", "хелло ворлд", "запилил тудушку", то есть шанс что это будет кому-то интересно.
Битва пет-проектов
Раскрываем карты и рассказываем о большой битве, к которой мы долго готовились.
25 сентября стартует битва пет-проектов: две команды начинающих IT-специалистов будут работать над одной идеей: создать место в интернете, где можно объединяться с единомышленниками и работать над IT-продуктами.
Победителей выбирает жюри и не только: за команды также могут голосовать хабраюзеры. Главный приз — стажировка в IT-компании для одного или нескольких участников битвы.
Под катом — про команды, экспертов, призы и с чего это всё вообще началось.