человек который придет кодить рядом скорее всего предположит что код уже работает
У него нет оснований так предполагать. Если есть явный условный переход, значит, условие может быть как истинным, так и ложным.
Но если нет кода - нет и сомнений. Поэтому разные ветки при прочих равных предпочтительнее.
На реальных проектах работают люди
Чтобы суметь таске указать родительскую фичу не нужно быть суперменом. Для эффективной работы нужно выстраивать процессы, это непосредственная задача менеджмента.
не говорите вписать в задачу - эту задачу закроют, а через пол года новую заведут
Именно это и скажу. Тот, кто принимает решение о приоритете задач обычно читает не код, а джиру. А если бэклог выглядит плоской помойкой без структуры, где всё теряется, то и высыпание мусора из нее себе под ноги ничего не даст, кроме повышенной когнитивной нагрузки и раздражения программистов.
Ну уж на крайний случай, если есть твердая уверенность, что эта доработка скоро понадобится, можно сделать компактный TODO-коммент с указанием на таску, где будет человеческаое описание целей с задачами и прилинкована ссылка на ветку с нужными коммитами. Но никак не зеленая лавина. И это не напоминание о том, что задачу надо делать.
Если же такой уверенности нет и пройдет порядочно времени, то такой код потерять не жалко, ведь его актуализация может занять сравнимое количество времени с разработкой с чистого листа.
В if (false) или не дай бог фиче тоггл завернуть - так не очевидно будет, что этот код не работает
Магическиие константы - это, вообще говоря, антипаттерн, у фича-флага должно быть говорящее имя (вроде ${featureName}Enabled). Если вам необходимо так гибко управлять включением фич, то наверняка будет полезно прокидывать его значение из основных настроек/переменных окружения/etc, чтобы не ползать по кодовой базе в поисках необходимого.
удалил код потому что он не нужен в этом релизе - а следующий разработчик не зная что эта фича была - написал её заново через один релиз а не вытащил из гита.
Если же вариаций мало и они известны на этапе сборки, то для разных дистрибутивов можно сделать просто разные корневые ветки (то есть форки). Или как вы себе представляете, скажем, хотфикс для первого релиза после второго, туда-сюда вручную изменения гонять?
Код первичен, а комментарии зависят от него, их нет никакого смысла выделять. Если вы заострили внимание на определенном участке кода, то едва ли серый цвет помешает ознакомиться с пояснением рядом. И вряд ли понадобится рыскать по файлу в поисках нужного комментария, не обращая внимание не структуру кода.
Ещё один секрет, о котором никто не говорит, заключается в том, что существует два типа комментариев:
Закомментированный код
Секрета нет, просто закомментированного кода не должно быть, ибо место ему - без комментирования в отдельных экспериментальных ветках или документации, а здесь это будет просто мусором.
Еще вариант - Donner HUSH-I (пьеза) и HUSH-X (магнитные датчики). Безголовые разделочные доски со съемными упорами) Наверное самое компактное в походном варианте, что можно сделать со стандартной мензурой и несъемным грифом.
Большинство изучающих джаву или дотнет - пишут бэк. Вообще сейчас программисты в подавляющем большинстве пишут веб на одной из сторон. Это человекоёмкая работа) Но это же не означает, что нет ничего кроме.
До этого мы обсуждали электрогитары, они генерируют полезный электрический сигнал, а слышымый звук от них скорее мешает (щелчки медиатора, звон струн и т.п.).
Смотря насколько мощный усилитель и какой звукосниматель/встроен ли кабсим. Пьезодатчику (обычно либо полоска под бриджевым порожком или блинчик, который прислоняют прямо на деку) и микрофонам не нужен симулятор гитарного кабинета, а магнитным звукоснимателям (как на электрогитарах) - нужен. А хватит ли усилителя - воткнитесь и оцените, достаточно ли запаса по громкости, в худшем случае будет слишком тихо.
Почему именно десктопные? Может есть какие-то истории успеха? Интересно было бы почитать про любые сколь-либо популярные софтины/применения вне веб-сервера.
Повторю мысли, которые уже звучали выше: дополнительные действия и правда нужны, но они шаблонные и в любом случае must know для профессионала, потратить недельку один раз и потом копипастить применять эти знания из проекта в проект - это не проблема. А любителю с бюджетом в три копейки - путь в социальные сети, это еще проще, еще надежнее, еще бесплатнее.
Отчасти. Нет какой-то единой сути, каждый находит свою. Гитара - отличное хобби, можно получать удовольствие от самого процесса игры или сочинения музыки. Почему бы не развлекать себя этим в путешествии или, скажем, в гостинице после работы?
И еще раз акцентирую внимание на aux: можно играть в любую портативную колонку, да хоть в аудиосистему автомобиля/мота, не нужен отдельный гробик исключительно для гитары.
Не знаю где вы такие дешевые VDS нашли виртуальный хостинг в любом случае намного дешевле
Не буду рекламу делать, но могу скинуть прайс:
скриншот
VPS/VDS - это тоже виртуальный хостинг, первая буква обязывает.
не требует никаколго дминистрирования настройки ПО и прочего в отличие от VDS.
Во-первых, многие хостеры предлагают предустановку привычной панели управления, во-вторых, минимальная настройка VPS описывается одним блоговым постом, коих уже миллион понаписано. Обслуживать VPS нужно не больше шареда.
зачем человеку который держит сайт для кафе или ИМ переплачивать если можно поставить WP на гаред хостинг
Про социалки рядом тоже в кассу заметили - они нынче достаточно могучие и имеют больше возможностей продвижения. Для типового решения не нужен WP. Для кастомного решения - лучше заплатить специалисту, чтобы не огрести проблем для бизнеса из-за дилетантских ошибок и получить качественный продукт. А специалисту это не преимущество.
WP - это как Excel на котором обширное использование макросов - это уже плохая идея.
чем дороже и сложнее стек и деплой тем лучше - больше денег.
Деплой всегда должен сводиться к кнопке с зеленой стрелочкой или запуску одного скрипта. Стеки чаще всего бесплатные, а сложность условного NodeJS не то, чтобы выше того же PHP.
У него нет оснований так предполагать. Если есть явный условный переход, значит, условие может быть как истинным, так и ложным.
Но если нет кода - нет и сомнений. Поэтому разные ветки при прочих равных предпочтительнее.
Чтобы суметь таске указать родительскую фичу не нужно быть суперменом. Для эффективной работы нужно выстраивать процессы, это непосредственная задача менеджмента.
Именно это и скажу. Тот, кто принимает решение о приоритете задач обычно читает не код, а джиру. А если бэклог выглядит плоской помойкой без структуры, где всё теряется, то и высыпание мусора из нее себе под ноги ничего не даст, кроме повышенной когнитивной нагрузки и раздражения программистов.
Ну уж на крайний случай, если есть твердая уверенность, что эта доработка скоро понадобится, можно сделать компактный TODO-коммент с указанием на таску, где будет человеческаое описание целей с задачами и прилинкована ссылка на ветку с нужными коммитами. Но никак не зеленая лавина. И это не напоминание о том, что задачу надо делать.
Если же такой уверенности нет и пройдет порядочно времени, то такой код потерять не жалко, ведь его актуализация может занять сравнимое количество времени с разработкой с чистого листа.
Магическиие константы - это, вообще говоря, антипаттерн, у фича-флага должно быть говорящее имя (вроде
${featureName}Enabled). Если вам необходимо так гибко управлять включением фич, то наверняка будет полезно прокидывать его значение из основных настроек/переменных окружения/etc, чтобы не ползать по кодовой базе в поисках необходимого.Если же вариаций мало и они известны на этапе сборки, то для разных дистрибутивов можно сделать просто разные корневые ветки (то есть форки). Или как вы себе представляете, скажем, хотфикс для первого релиза после второго, туда-сюда вручную изменения гонять?
Код первичен, а комментарии зависят от него, их нет никакого смысла выделять. Если вы заострили внимание на определенном участке кода, то едва ли серый цвет помешает ознакомиться с пояснением рядом. И вряд ли понадобится рыскать по файлу в поисках нужного комментария, не обращая внимание не структуру кода.
Секрета нет, просто закомментированного кода не должно быть, ибо место ему - без комментирования в отдельных экспериментальных ветках или документации, а здесь это будет просто мусором.
А что, если...это хитрый план ИИ, дабы его внедрение происходило активнее?)
Неудачники нам не нужны! (c)
Как раз сегодня попалась новость.
Еще вариант - Donner HUSH-I (пьеза) и HUSH-X (магнитные датчики). Безголовые разделочные доски со съемными упорами) Наверное самое компактное в походном варианте, что можно сделать со стандартной мензурой и несъемным грифом.
hush-x
Большинство изучающих джаву или дотнет - пишут бэк. Вообще сейчас программисты в подавляющем большинстве пишут веб на одной из сторон. Это человекоёмкая работа) Но это же не означает, что нет ничего кроме.
До этого мы обсуждали электрогитары, они генерируют полезный электрический сигнал, а слышымый звук от них скорее мешает (щелчки медиатора, звон струн и т.п.).
Смотря насколько мощный усилитель и какой звукосниматель/встроен ли кабсим. Пьезодатчику (обычно либо полоска под бриджевым порожком или блинчик, который прислоняют прямо на деку) и микрофонам не нужен симулятор гитарного кабинета, а магнитным звукоснимателям (как на электрогитарах) - нужен. А хватит ли усилителя - воткнитесь и оцените, достаточно ли запаса по громкости, в худшем случае будет слишком тихо.
Не надо. В гитару втыкается коробочка на батарейках, а в нее уже - aux с источником звука на другом конце.
Vox Amplug2
усилитель + кабсим + джентльменский набор эффектов (овердрайв/дисторшн, делей, реверб).
Ваши примеры эти два направления не покрывают, как бы)
А конечные продукты какие-то с их помощью делают или это демо ради самой возможности? Сравнимы ли они по популярности, скажем, с RoadRunner?
Это уже два направления, тащемта.
Почему именно десктопные? Может есть какие-то истории успеха? Интересно было бы почитать про любые сколь-либо популярные софтины/применения вне веб-сервера.
Это ж язык общего назначения, на нем можно что угодно прикладное написать. А нужно ли именно на нем - это уже другой вопрос.
Повторю мысли, которые уже звучали выше: дополнительные действия и правда нужны, но они шаблонные и в любом случае must know для профессионала, потратить недельку один раз и потом
копипаститьприменять эти знания из проекта в проект - это не проблема. А любителю с бюджетом в три копейки - путь в социальные сети, это еще проще, еще надежнее, еще бесплатнее.На Go, к примеру, пишут системные утилиты (Docker, K8s, из недавнего - портирование tsc), а PHP где-то за границами веб-морд используется?
Отчасти. Нет какой-то единой сути, каждый находит свою. Гитара - отличное хобби, можно получать удовольствие от самого процесса игры или сочинения музыки. Почему бы не развлекать себя этим в путешествии или, скажем, в гостинице после работы?
И еще раз акцентирую внимание на aux: можно играть в любую портативную колонку, да хоть в аудиосистему автомобиля/мота, не нужен отдельный гробик исключительно для гитары.
Vox Amplug и наушники или любой другой источник звука с aux. Едва ли 100 грамм выйдет и соответствующие габариты.
Не буду рекламу делать, но могу скинуть прайс:
скриншот
VPS/VDS - это тоже виртуальный хостинг, первая буква обязывает.
Во-первых, многие хостеры предлагают предустановку привычной панели управления, во-вторых, минимальная настройка VPS описывается одним блоговым постом, коих уже миллион понаписано. Обслуживать VPS нужно не больше шареда.
Про социалки рядом тоже в кассу заметили - они нынче достаточно могучие и имеют больше возможностей продвижения. Для типового решения не нужен WP. Для кастомного решения - лучше заплатить специалисту, чтобы не огрести проблем для бизнеса из-за дилетантских ошибок и получить качественный продукт. А специалисту это не преимущество.
WP - это как Excel на котором обширное использование макросов - это уже плохая идея.
Деплой всегда должен сводиться к кнопке с зеленой стрелочкой или запуску одного скрипта. Стеки чаще всего бесплатные, а сложность условного NodeJS не то, чтобы выше того же PHP.
Костыль, чтобы затащить PHP на лямбду? Преимущества отклеились же.