Comments 38
Добрый день. Вижу минус. Знакомая проблема, бро. В здоровом обществе за откровение автоматом плюс, но не тут же.
Я хотел бы услышать кулстори про то как правильно не умереть под водой. Поделитесь.
"Хотя аппарат выдерживает сильное глубоководное давление, любой дефект в его форме или конструкции может стать фатальным — причем есть риск взрыва", — говорит ученый.
Оборудование весит около 15кг, так кроме него вам ещё пихают грузила в карманы, чтобы компенсировать плавучесть самого комбенизона — он давольно сильно выталкивает наверх.
По какой-то причине в группе только у меня был электронный комплект датчиков, который ещё и пищал («Расслабься, он просто думает, что ты шестой раз погружаешься, а это вредно»). Ну ок.
Всё было нормально до глубины примерно в 5 метров, если не считать какого-то звука, похожего на моторчик. Я подумал, что это просто мимо лодка проплывают и остальные тоже его слышат (не слышали). После 5 метров резко похолодало и спустя буквально минуту я понял, что воздух не поступает. Я выплюнул шланг, перевернул выходом вниз и нажал на клапан — ноль эффекта.
Я подал жест инструктору, что меня нужно поднять, но он это проигнорировал или не заметил, потому что я замыкал группу. Нас предупредили, что всплывать самостоятельно это дважды плохая идея. Первая причина — сделать это со всем оборудованием очень сложно.
Так как жесты не помогли, я начал изо всех сил плыть наверх. Спустя минуту длиною вечность я сделал глоток воздуха, но радовался недолго, потому что вспомнил вторую причину — попытки удержаться на плаву просто вымотают тебя. Мне повезло, что там проплывали ребята, которые надули мне жилет (меня не проиструктировали, что так вообще можно) и дотащили до камней.
электронный комплект датчиков, который ещё и пищал («Расслабься, он просто думает, что ты шестой раз погружаешься, а это вредно»)
Я подал жест инструктору, что меня нужно поднять, но он это проигнорировал или не заметил
И тамада хороший, и конкурсы интересные...
Вы просто походу ныряли с какими-то дебилами.
Как так вышло что из-за смены версии vue - сборка и деплой уменьшились на порядки? О чем вы не договариваете?
Автор указал, что был webpack, а стал vite. Никаких подводных камней.
Всё верно, переехали на Vite и сборка стала быстрее.
Также у нас деплой включает в себя ещё и запуск тестов и выгрузку на сервер. Тут мы получили прирост за счёт:
Vitest, который в нащем случае быстрее Jest.
Удаления кучи зависимостей. Например, у нас была практика использовать пакеты, чтобы решать задачи, которые в одну строку решаются силами JS.
Удаления Nuxt. Теперь билд — это не приложение, которое нужно запускать, а просто статические файлы.
Что-то не понял мораль сей басни. Вот это что ли?
Люди работали недостаточно, чтобы закрыть переезд в срок.
Мораль вот тут:
Не будьте героем.
Когда человек геройствует на старете, то это хорошо, потому что иначе никак. Если запуск уже состоялся и позиции компании укрепились, что это моментально становится антипаттерном, потому что скрывает косяки менеджмента.
Тут нужна работа на два фронта:
Бизнесу сказать «Мы всё это время работали на 200%, но дальше так нельзя. Да, мы всё ещё можем быстро катить фичи, но фич будет меньше, потому что сразу после этого нужен рефактор/написание тестов. Иначе в будущем схлопнемся, потому что код станет write only».
Команде сказать «Я по выходным не работаю и вам не советую». Работать, конечно, можно, просто людям показывать нельзя.
А мне кажется тут просто неопытность и инфантилизм главного героя (что подтверждают видосики)
Вариант 1. Оценить время и ресурсы перехода, проконсультироваться с парой профессионалов, которые такое уже делали, скорректировать сроки, умножить на полтора и предоложить план перехода бизнесу со всеми "за" и "против" (типа билд время Vite против Webpack и, следовательно, скорость работы)
Вариант 2. Постепенно переписывать всё время имея рабочую версию. Сперва на Vue 2.7. Убрать миксины, фильтры, все другое ненужное, затем постепенно переписать на Composition API. Убрать Vuex. Потом Vue 3 и обновление зависимостей. Потом Vite. Займёт дольше, но менеджмент не будет нервничать, и сроки будут плавающие
А "герой" / "не герой", работать на "200%" - это лирика какая-то
Уволить надо такого СТО. И вот, почему:
Во-первых, если работник работает больше 40 часов в неделю, это значит, что он не справляется с возложенными на него обязанностями. Соответственно, это либо просто плохой работник, либо он не соответствует должности.
Во-вторых, заниженные эстимэйты - это воровство у компании. СТО украл, а рассчитываться либо собственнику фирмы, оплачивая дополнительные часы работы, либо работникам путём переработок, либо и то, и другое вместе. И не надо думать, что это я преувеличиваю. Если из офиса, к примеру, украсть компы, для собственников это будет выглядеть точно так же.
Удачи, CTO собственник.
UPD: CTO предложил вариант миграции, а не утвердил его — это уже моя заслуга.
Вот интересно, без переделки всего с нуля, насколько бы различалось время?
Мы уже год переезжаем на Vue 3. Постранично, постепенно. Зато продуктовые задачи не останавливаем, просто берем по страничке в релиз.
Поддерживаете две версии сразу или Vue3 просто лежит в сторонке и ждёт своей очереди?
Мы рассматривали Bridge, Module Federation или даже веб-компоненты, но решили не извращаться таким образом.
Продуктовые задачи тоже не замораживали — что-то новое появилось в проекте на Vue3, что-то добавляли в ещё не перенесённые страницы на Vue2. Просто объём сократился в разы.
Имеем 2 отдельных проекта. Отдельные URL обслуживаются старым проектом, отдельные URL обслуживаются новым проектом. Редиректы сделаны на стороне nginx + kubernetes. Т.е. у нас базовая единица разделения - отдельный URL.
Проблемы следующие: первый шаг очень большой, потому что нужно сделать один и тот же layout в старом и новом фронте, меню, модалки, панели, каркас и т.д.
Сложно мигрировать большие навороченные страницы со сложной логикой. Бывают такие страницы, которые мега навороченные по функционалу. Таких страниц у нас немного, остальные страницы в основном несложные мигрируются просто.
А как шарите стейт?
У нас особого стейта нету. Пара примеров: количество непрочитанных уведомлений в нотификациях, пара восклицательных знаков в меню на разделах, на которые пользователю надо обратить внимание (документы просрачиваются например, надо загрузить новые).
Эти стейты загружаются отдельными API запросами. Т.е. при переходе на новый фронт полностью перезагружается весь фронт (полное обновление страницы), и делаются API запросы на получение всех необходимых "восклицательных знаков (стейтов), которые надо показать пользователю", и потом пока пользователь ходит по новому фронту стейты не загружаются, потом при переходе на старый фронт снова все загружается через API.
Данные страниц не кешируются. Т.е. если пользователь зашел в таблицу каких-то данных, то при очередном переходе на эту страницу данные загрузятся заново.
или даже веб-компоненты
Можно подробнее? Интересно, правда
Вот тут хороший пример: https://www.youtube.com/watch?v=CaP5eAylYpI
Да это самое планирование задач - вообще какой-то бич. Почему то, люди думают, что будущее возможно предсказать. На тему менеджмента и планирования. Однако забывают тот простой факт, что сама информация предсказания уже влиет на будущее.
Допустим, есть зеркало, которое предсказывает будущее. Вопрос: брать ли зонт? Если в зеркале ты мокрый - возьмешь зонт и будешь сухим. Если сухой - зонт не возьмешь и будешь мокрый. Парадокс. Проблема самореференции.
И начинается потом поиск виноватых - мол, кто же у нас "плохой"? Хотя виноваты вообще - все, даже я, ибо не сказал вам этого раньше. Мне импонирует позиция - валить все на менеджмент - их не жалко, но решение проблем через поиск виноватых - контрпродуктивно. Никогда еще тюрьма никого не исправляла, как и отрезание рук в Саудовской Аравии не излечивает бедность и воровство.
Тупо планирование процесса на вере в "периодичность" процессов дает сбой, ибо сама периодичность - мнимая. Сколько бы людей не умерли от голода, если бы предполагали возможность засухи, а не считали бы, что летом априори всегда идёт дождь?
И, мол, можно пусть не наверняка, но с какой то точностью дать прогноз. Но это именно, что - прогноз. Его точность всегда 50% - либо сбудется, либо - нет. Прогнозы можно давать лишь на 100% повторяющиеся процессы, причем точность выше, чем выше количество повторений. У Вас - оно всего теперь всего одно, вы один раз перешли с этого конкретного стека на другой конкретный. Теперь, вы можете планировать. И даже предполагать сроки. До этого - вы просто гадали. Да и теперь - периодичность будет мнимая, ибо одно повторение - не периодично, это лишь единичный случай, а не повторение. Я могу дать более-менее точный прогноз лишь на количество нажатий на кнопку за еденицу времни. И то - с предварительными расчетами. А там - может руку сведет, комп зависнет, палец устанет и т.д. Чтобы все факторы учитывать - нужна вся информация. А информации - бесконечно. Тогда, каким образом учесть точность прогноза (в процентах) если есть, допустим, лишь петабайт информации из бесконечного количества? Предел точности прогноза тогда всегда стремится к 0%, ибо c/∞=0
Лично я все равно буду геройствовать - мне это по фану. Мол, успею я за неделю сделать то, что невозможно сделать за неделю? Чисто челендж. Но да, это выматывает, тут уже вопросы здоровья - нужно следить за количеством отдыха и никогда не ставить зарабатывание денег другим людям (и даже себе) выше собственного здоровья. Но, к сожалению, основам здравоохранения, в том числе психического - ни в школах ни в спец/высших не учат.
У вас проблема с целеполаганием и подменой целей.
Ваша цель "переехать с Vue2 на Vue3". Ещё раз повторю, изначально есть Vue2, а нужно Vue3. Всё, больше ничего.
Но вам было скучно, поэтому вы придумали себе дополнительные соревнования (челеджи), например, ограничили переезд количеством задач (120) и ограничили время (1 месяц). Из-за этих выдуманных ограничений вы загоняли себя и свою команду, занимались микроменеджментом, сами писали код, напрягали людей и остались по итогу ими недовольны. Не надо так.
Я всегда говорю коллегам:
1. Всем плевать на сроки. Если то, что вы делаете, важно для бизнеса, то бизнес всегда будет готов увеличивать сроки и затраты на этот проект. Если же это какая-то ерунда, то нет ничего плохого в том, что проект умрёт ещё на начальной стадии, когда станет ясно, что его долго или дорого делать. Правило 20 на 80 тут отлично подходит.
2. Когда проект закончен, всем плевать, уложился он в какие-то выдуманные сроки или нет. Через полгода об этом никто и не вспомнит. Всем важно итоговое качество. Если проект уложился в сроки, но качество его реализации г...вно, то вы получите клеймо г...внодела и текущее качество проекта будет напрямую связано с вашим именем. Г...вняные проекты - это плохой вариант для получения премий и продвижения в карьере.
3. Корректно определять сроки можно только для тех проектов, которые ранее уже выполнялись именно этой командой, т.е. когда известны все подводные камни и пути их обхода. Для новых и неизвестных проектов самый продуктивный вариант - это просто начинать делать работу, а не тратить время на попытки угадать сроки реализации. После 2-х недель активной работы будет понятно, какой примерно % проекта был сделан за это время. Это число экстраполируется до 100% проекта, а потом умножается на 2. Если итоговое время всех устраивает, то проект можно продолжать. Если все говорят, что это слишком долго, то либо урезаем объём проекта, либо просто его закрываем и перестаём тратить на него силы.
P.S. Когда-то давно я был таким же героем, как вы сейчас. Но теперь, имея за спиной десятки проектов, кучу прочитанных книг и несколько смен компаний, я перестал геройствовать, да и здоровье, убитое во время геройства, уже не позволяет повторять 12 часовые рабочие марафоны.
Вот п.3 на этом проекте не помог бы:
из 120 задач к концу первого месяца было сделано 80.
Значит за первые две недели было сделано примерно 40.
Примерно 20 задач в неделю. Получается, что под оставшиеся 80 задач нужно было просить еще (80 задач / 20 задач_в_неделю) * 2 = 8 недель = 2 месяца,
а общая длительность проекта была бы запланирована на 10 недель, чуть больше двух месяцев.
По факту проект занял еще вдвое больше времени.
Мне когда я учился оценке сроков профессор сказал что умножать надо на Pi=3.14157
1) в два это мало
2) все будут думать что это хитрая формула, которую они не знали, и постесняются критиковать.
3) можно сказать что цель видна но пути реализации не прямые а кругами по этому Pi
Если такой коэффициент видит ваш начальник, то он может и сообразить, что достоверность оценки трудоемкости обратно пропорциональна этому коэффициенту. То есть показывая 3.14 вы объявляете, что знаете о проекте чуть более 30% факторов, а всё остальное для вас темный лес.
Это может привести к некоторым сомнениям в компетентности оценивающего.
По факту вам просто надо было переезжать постепенно, начав с вебпака (по моему опыту у него в таких случаях обычно самые большие проблемы с зависимостями). А уже после перетаскивать всё остальное.
Бутстрап в коммерческом проекте это вообще позор. Как и nuxt, но тут бывают варианты.
Что касается планирования, это и вовсе классическая глупость, о чём тут выше несколько человек написали — планирование придумали менеджеры, чтобы отчитываться какие они молодцы. Не превращайтесь в убогого, прекратите уделять столько времени на тайм-трекинг. Задача занимает столько сколько должна. Если её не верно оценили, значит надо переоценить и на этом всё.
А что не так с бутстрапом?
Да всё не так. Это перегруженный мусор.
По факту ещё и бесполезный. Я не видел ни одного крупного проекта где бы использовался только бутстрап без своих стилей. А раз люди используют ещё и другие стили, встаёт вопрос - зачем там вообще бутстрап?
В нём есть отдельные неплохие части, вроде позиционирования (или иконок, но там спорно), но полно гораздо более минималистичных фреймворков, которые можно использовать для этой цели.
Имхо для всех было бы только лучше, если б он вообще не существовал - было бы меньше больших кривых проектов.
В сообщении делается вывод о прошлом, находясь в настоящем. Сейчас бутстрап конечно же является рудиментом, но в середине десятых это был удобный инструмент
Да никогда он таким не был, не пишите чепухи. Это всегда был перегруженный мусор.
Причём сейчас они хотя бы додумались делить свой scss на модули, чтоб не импортить всё это говно целиком, а пару версий назад такой опции не было вовсе.
Я могу понять аргумент "это удобно", сам пользовался пару раз для прототипирования, просто потому что это быстро. Но назвать это "хорошим фреймворком" нельзя ни сейчас, ни когда-либо ранее. Это удобный инструмент чтоб сделать прототип какого-нибудь одностраничника и не более. Вот только его используют не только для прототипирования, это одна из причин почему любой активный пользователь интернета ежедневно грузит под пару сотен метров лишнего говнокода.
Лично я использовал бутстрап т.к. там удобные grid: кроссбраузерно и адаптивность под разные экраны.
Т.к. я не фронтенд разработчик, подскажите, что сейчас принято для этих целей использовать?
Не будьте героем