Теперь бы еще дойти до системы, которая реально полезна, и было бы вообще замечательно. А так, сколько я подобных вещей не видел (от игр до аниме до фильмов до музыки) — они более-менее работают только на очень неискушенного человека, для которого, на самом деле, единственный критерий рекомендаций — не рекомендовать ему совсем уж шлак, который вызовет негатив.
Если же человек немного повидал/послушал сам, полезность систем рекомендаций резко уходит в ноль. Например, что-то вменяемое в рекомендациях нетфликса для меня закончилось на третий день залипания в сериальчики, и дальше нужно было уже банально сидеть и перетряхивать всё вручную (а нетфликс интерфейсно довольно убог в этом разрезе, например).
Загуглите «гидравлический удар». В бытовых квартирных случаях он запросто будет случаться от простого открытия-закрытия кранов где-то неподалеку в системе. В результате этой всей болтанки гибкую подводку рано или поздно где-то рвёт.
Подключаться гибкими подводками можно, но чем они длиннее и чем больше их может шатать гидравликой — тем чаще их нужно осматривать и менять, если резина выглядит неоч (рвёт их в абсолютном большинстве случаев в местах соединения, а не где-то там).
Если ваша единственная проблема — разобраться с чьими-то духовными и эстетическими страданиями по поводу малозначительных деталей дизайна — мне кажется, что вы могли бы и чем-то гораздо более продуктивным заняться.
Тем более, что вы на самом деле разбираетесь исключительно со своими собственными возвышенными чуйствами, а не с чьими-то еще — ваши страдания над подчёркиванием и сглаживанием будут выглядеть совершенно иначе на других мониторах, операционных системах, и прочих разных условиях просмотра. Не говоря уж про разных людей. Вы вот страдаете над мелкими шрифтами, а лично я готов вломить каждому любителю поставить шрифт меньше 1rem канделябром, потому что у меня не настолько хорошие глаза, чтоб это потом разбирать.
Но в широком случае — типа, взял светлую тему, что-то там инвертировал или перемножил на коэффициент и получил темную — это абсолютная утопия. Поэтому без ручного вмешательства, увы, не обойтись.
Да ну нет конечно. Но вот когда надо передать определенные эффекты (тени, блики, тому подобное) — тут как раз нужны больше отношения между цветами, чем ручная работа. И статья абсолютно правильно утверждает, что RGB ну очень неудобен для описания таких отношений.
По мне с цветами вообще нет проблем после добавления колорпикера в браузеры. Цвета подбираются индивидуально, копипастятся в css. Вам даже смотреть не надо что вы копипастите.
Подбор индивидуальных цветов абсолютно везде — плохо масштабируется. Есть цвета естественным образом зависимые, например, всякого рода тени (чтоб получить естественный эффект). Если градиенты для тени сидеть и кодировать индивидуально подобранными цветами — ну, удачи вам потом изменять пачку из 5 RGB-значений, когда кто-то со стороны захочет чуть другого оттенка.
Мир фронтэнда давно уже сложнее, чем использование захардкоженных цветов ради раскраски кнопочек.
Так собственно везде, где используется система контроля версий) Если бы без нее было быстрее, все бы так и делали.
Я так до сих пор не понял, почему вы обсуждаете дихотомию «есть контроль версий»/«нет контроля версий», хотя в этой ветке весь разговор про «есть хорошая историях коммитов»/«нет хорошей истории коммитов».
Без хорошей истории коммитов в причинах правок кода тоже прекрасно разбираются. Просто тратят больше времени на это.
Если изменение API связано с внутренними изменениями, они должны быть в одном коммите. Зачем их разделять?
Затем, что такие правки с легкостью порождают огромные (по объему) коммиты, в которых потом будет долго разбираться при анализе истории.
Только почему-то в конечном счете оказывается, что это время не экономит, а совсем наоборот.
Или не оказывается. У вас есть какие-то конкретные случаи, или это всё умозрительно?
К примеру
Примеры у вас, конечно же, все тривиальные. Про более сложные случаи в таких обсуждениях вспоминать почему-то не любят — скажем, как выделять в коммитах изменение внешних API каких-то модулей вследствие их внутренних изменений.
Если у вас на это уходит много времени, значит вы делаете что-то не так.
На это уходит значительно больше времени, чем на подробное документирование целых PR, а не отдельных коммитов.
Понятно, что не дни. Но по часу-другому в неделю на разработчика вполне себе может набраться. У вас 10 разработчиков? Ну вот — оп, и 10-20 часов в неделю уходит на причёсывание коммитов.
Ну у реакта есть проблемы, да, из-за дурных моментов обработки vdom. К реакту даже вебкомпоненты так просто не привязываются (придётся немного оборачивать), что уж говорить.
Но в целом всё равно можно, хоть и немного более заковыристо, чем обычно.
Зависит от состояния кода, количества зависимостей, состояния документации, и проч.
Самая энтерпрайз-классика — какое-то не самое очевидное поведение было реализовано для конкретного клиента, а затем спустя много времени уже другому клиенту оно не нравится. Устраняем — через некоторое время нам как снег на голову сваливается первый клиент, у которого вдруг всё поломалось.
Так-то это конечно всё задокументировано должно быть. Но в реальном мире бывает по-всякому.
Если вам не нужно анализировать историю, то вам и система контроля версий не нужна.
Конечно. И идеал — именно такой, а стремление к идеалу — минимизация количества причин, по которым нужно анализировать историю.
Причина анализа истории это предыдущие изменения в коде. Причина внесения изменений в код это рабочие задачи.
Ну нет. Причина анализа истории — это неочевидность смысла появлений тех или иных изменений в коде. То есть, условно говоря, когда ничего не задокументировано, нет ТЗ, и вообще не очень понятно, что мы тут все делаем (что-то фигачим на основе какого-то расплывчатого видения в чьих-то головах) — действительно, очень легко можно оказаться в ситуации, когда меняя что-то в коде мы нарушаем ранее установленные важные соглашения (которые, однако, нигде не описаны).
И да, одно из мнений — это то, что вести архив подобных вещей как раз и нужно именно в истории коммитов, а не где-то еще. Но это не «единственное правильное» решение, а всего лишь компромисс — ведение хорошей истории коммитов постоянно жрет человеко-часы, рытьё в коммитах (если мы не ведем хорошей истории) — аналогично, только не постоянно, а в момент возникновения проблем. В разных ситуациях выгодность первого и второго пути будут сильно различаться.
Конечно нет. В большинстве случаев это попытка разобраться с происхождением багов — для этого можно или заставлять всех делать атомарные коммиты и описания, или же, например, писать код понятнее, прогонять тесты, пользоваться статической типизацией, и так далее.
Короче, если вам необходимо много рыться в истории, то причина этого — очевидно, не плохое ведение оной истории. Когда вы пытаетесь вести историю получше, чтоб тратить меньше времени на копание в ней — вы боретесь со следствиями, а не с причинами.
Когда мне ярые сторонники атомарнейших коммитов с подробнейшими commit message предлагают делать так, я в ответ обычно предлагаю поднять историю откатов коммитов (потому что это главный кейс экономии времени с атомарными коммитами). Если выясняется, что откатов исчезающе мало (а в энтерпрайзе обычно именно так и оказывается) — самое время подумать про потери времени на описание коммитов и перестройку работы на атомарные задачи.
Работает оно как угодно, но про это Фил уже написал. И так работает, и с PR работает, и даже работает, когда все тупо фигачат в мастер без ревью. Вопрос исключительно в том, насколько плохо может быть поставлен процесс разработки, чтоб при этом всё не развалилось и не поимело проблем. Про границы применимости тех или иных best practices обычно мало кто думает (впрочем, я про это даже статейку тиснул): небольшой продукт, разрабатываемый небольшой командой — легко может быть свалкой коммитов без каких-либо проблем для себя, а если там еще и тестами всё хорошо покрыто — то и не небольшой. Что-то большое и/или сложное, да еще и если от этого требуется повышенное качество и хороший bus factor — … тоже может, но уже может и поиметь крупные проблемы из-за неорганизованного принятия кода.
А вот у опенсорса совсем другие реалии, например, и там я бы хорошие атомарные коммиты ценил гораздо выше.
Учитывая, что на Delphi делалось очень много наколенной частной автоматизации (или в пределах одного рабочего места, или чуть распределенно, но всё равно очень частно) — логично предположить, что это как раз тот вариант, при котором выкинуть имеющееся и заменить его более общим решением (1C и подобным) наиболее просто.
И да, аргумент про пиратское — тоже был крайне весомым, проблем с законом из-за софта мало кто хотел, а при легализации (венду купи, базу, если она не игрушечная борландовская — тоже купи, и так далее) делфи быстро переставала быть дешевой.
Я чёт не вижу, как что-то «мощное» по способностям может быть «слабым». Не всегда удобно — да. Выводить типы иногда очень заморочено — тоже да. Но если б все писали только на удобном, ассемблера бы не существовало.
По крайней мере, библиотеки сложных типов к TS люди уже начали делать, так что не везде надо делать всё самому.
Зарплаты выше среднего по какому-то языку — это всего лишь видимый результат перекоса спроса и предложения. Оно плохо коррелирует с заявленной темой статьи, так как может быть результатом множества разных ситуаций. Например — технология умирает, а легаси очень много. Зарплаты высокие, потому что количество желающих сокращается сильно быстрее объемов легаси (обычно из-за фундаментальных проблем именно самой технологии или появления лучших альтернатив). Но тренд технологии исключительно нисходящий, и желающих влиться в это дело в далеком будущем как максимум ждет непыльное местечко а-ля COBOL и государственный софт в США. Но таких мест будет очень мало, и всех, кто не смог на них попасть, ждет гораздо более прозаичный вариант: увольнение и отсутствие другой профильной работы.
Или банальная редкость технологий: если несколько крупных компаний связались с какой-то технологией, а она так и не «взлетела», то из-за острого желания найти нормальных работников — зарплаты предлагаются большие, но объем трудового рынка для этих технологий — мизерный, и скорее всего таким и останется.
Смотреть только на зарплаты — занятие сомнительное.
Если же человек немного повидал/послушал сам, полезность систем рекомендаций резко уходит в ноль. Например, что-то вменяемое в рекомендациях нетфликса для меня закончилось на третий день залипания в сериальчики, и дальше нужно было уже банально сидеть и перетряхивать всё вручную (а нетфликс интерфейсно довольно убог в этом разрезе, например).
Подключаться гибкими подводками можно, но чем они длиннее и чем больше их может шатать гидравликой — тем чаще их нужно осматривать и менять, если резина выглядит неоч (рвёт их в абсолютном большинстве случаев в местах соединения, а не где-то там).
Тем более, что вы на самом деле разбираетесь исключительно со своими собственными возвышенными чуйствами, а не с чьими-то еще — ваши страдания над подчёркиванием и сглаживанием будут выглядеть совершенно иначе на других мониторах, операционных системах, и прочих разных условиях просмотра. Не говоря уж про разных людей. Вы вот страдаете над мелкими шрифтами, а лично я готов вломить каждому любителю поставить шрифт меньше 1rem канделябром, потому что у меня не настолько хорошие глаза, чтоб это потом разбирать.
Да ну нет конечно. Но вот когда надо передать определенные эффекты (тени, блики, тому подобное) — тут как раз нужны больше отношения между цветами, чем ручная работа. И статья абсолютно правильно утверждает, что RGB ну очень неудобен для описания таких отношений.
Подбор индивидуальных цветов абсолютно везде — плохо масштабируется. Есть цвета естественным образом зависимые, например, всякого рода тени (чтоб получить естественный эффект). Если градиенты для тени сидеть и кодировать индивидуально подобранными цветами — ну, удачи вам потом изменять пачку из 5 RGB-значений, когда кто-то со стороны захочет чуть другого оттенка.
Мир фронтэнда давно уже сложнее, чем использование захардкоженных цветов ради раскраски кнопочек.
Я так до сих пор не понял, почему вы обсуждаете дихотомию «есть контроль версий»/«нет контроля версий», хотя в этой ветке весь разговор про «есть хорошая историях коммитов»/«нет хорошей истории коммитов».
Без хорошей истории коммитов в причинах правок кода тоже прекрасно разбираются. Просто тратят больше времени на это.
Затем, что такие правки с легкостью порождают огромные (по объему) коммиты, в которых потом будет долго разбираться при анализе истории.
Или не оказывается. У вас есть какие-то конкретные случаи, или это всё умозрительно?
Примеры у вас, конечно же, все тривиальные. Про более сложные случаи в таких обсуждениях вспоминать почему-то не любят — скажем, как выделять в коммитах изменение внешних API каких-то модулей вследствие их внутренних изменений.
На это уходит значительно больше времени, чем на подробное документирование целых PR, а не отдельных коммитов.
Понятно, что не дни. Но по часу-другому в неделю на разработчика вполне себе может набраться. У вас 10 разработчиков? Ну вот — оп, и 10-20 часов в неделю уходит на причёсывание коммитов.
Но в целом всё равно можно, хоть и немного более заковыристо, чем обычно.
Самая энтерпрайз-классика — какое-то не самое очевидное поведение было реализовано для конкретного клиента, а затем спустя много времени уже другому клиенту оно не нравится. Устраняем — через некоторое время нам как снег на голову сваливается первый клиент, у которого вдруг всё поломалось.
Так-то это конечно всё задокументировано должно быть. Но в реальном мире бывает по-всякому.
Конечно. И идеал — именно такой, а стремление к идеалу — минимизация количества причин, по которым нужно анализировать историю.
Ну нет. Причина анализа истории — это неочевидность смысла появлений тех или иных изменений в коде. То есть, условно говоря, когда ничего не задокументировано, нет ТЗ, и вообще не очень понятно, что мы тут все делаем (что-то фигачим на основе какого-то расплывчатого видения в чьих-то головах) — действительно, очень легко можно оказаться в ситуации, когда меняя что-то в коде мы нарушаем ранее установленные важные соглашения (которые, однако, нигде не описаны).
И да, одно из мнений — это то, что вести архив подобных вещей как раз и нужно именно в истории коммитов, а не где-то еще. Но это не «единственное правильное» решение, а всего лишь компромисс — ведение хорошей истории коммитов постоянно жрет человеко-часы, рытьё в коммитах (если мы не ведем хорошей истории) — аналогично, только не постоянно, а в момент возникновения проблем. В разных ситуациях выгодность первого и второго пути будут сильно различаться.
Короче, если вам необходимо много рыться в истории, то причина этого — очевидно, не плохое ведение оной истории. Когда вы пытаетесь вести историю получше, чтоб тратить меньше времени на копание в ней — вы боретесь со следствиями, а не с причинами.
Работает оно как угодно, но про это Фил уже написал. И так работает, и с PR работает, и даже работает, когда все тупо фигачат в мастер без ревью. Вопрос исключительно в том, насколько плохо может быть поставлен процесс разработки, чтоб при этом всё не развалилось и не поимело проблем. Про границы применимости тех или иных best practices обычно мало кто думает (впрочем, я про это даже статейку тиснул): небольшой продукт, разрабатываемый небольшой командой — легко может быть свалкой коммитов без каких-либо проблем для себя, а если там еще и тестами всё хорошо покрыто — то и не небольшой. Что-то большое и/или сложное, да еще и если от этого требуется повышенное качество и хороший bus factor — … тоже может, но уже может и поиметь крупные проблемы из-за неорганизованного принятия кода.
А вот у опенсорса совсем другие реалии, например, и там я бы хорошие атомарные коммиты ценил гораздо выше.
И да, аргумент про пиратское — тоже был крайне весомым, проблем с законом из-за софта мало кто хотел, а при легализации (венду купи, базу, если она не игрушечная борландовская — тоже купи, и так далее) делфи быстро переставала быть дешевой.
По крайней мере, библиотеки сложных типов к TS люди уже начали делать, так что не везде надо делать всё самому.
Или банальная редкость технологий: если несколько крупных компаний связались с какой-то технологией, а она так и не «взлетела», то из-за острого желания найти нормальных работников — зарплаты предлагаются большие, но объем трудового рынка для этих технологий — мизерный, и скорее всего таким и останется.
Смотреть только на зарплаты — занятие сомнительное.
Эм. И как и куда можно «спустить» циклон/антициклон?