Данияр Кудайбергенов: в зависимости от сложности задачи. По хорошему, главный человек (может быть любым из оставшихся трех) должен понимать примерно сколько стоит работа каждого участника. Если бэкенду надо только натянуть верстку на шаблон в вордпрессе, то платить ему за эту работу столько, сколько в среднем эта работа стоит на фрилансе.
Александр Логинов-Солоницын: проблема уже давно решена, так как есть ответ, помеченный решением. Искать лучший минификатор методом перебора не самое лучшее вложение времени.
Nekto_Habr: так составление палитры и основано на математике по сути. Есть определенные законы, по которым определяют сочетаемость цветов, например если визуально посмотреть на любой подход, то там будет гармоничное расположение точек на цветовом круге - хоть монохромное сочетание, хоть аналогичное и все прочие. В музыке также - можно наугад ткнуть по клавишам и получить аккорд случайный, но средствами математики, можно этот аккорд вычислить и не нажимая клавиш.
Дмитрий: у меня такой же шрифт используется и никаких проблем нет)
Там какие то специфичные для сафари псевдоклассы применены видимо, типа font-smoothing
А толщину шрифта не увидел с телефона)
Показалось что он просто прозрачнее там
Не совсем то, что нужно((
Я искал "математический" принцип для выбора этих цветов)
И на светлом и на темном фоне они должны быть достаточно контрастны, а так же сочетаться с цветами основной палитры
Nikita Schipilov: попробуй всетаки вручную написать transition: 0.6s )
либо выкладывай сам миксин)
еще как вариант попробуй на ховере только opacity менять без бэкграунда
Дмитрий КовальскийRyuk ...: "Но дело в том, я как программист, не хочу за каждым пуком обращаться к заказчику или аналитику для разъяснений. "
Вот для того, чтобы не обращаться каждый раз, все основное надо выспросить у заказчика на начальном этапе при первой встрече, а потом, если вдруг всплывет что то неожиданное, то можно и уточнить, но никак не делать на свое усмотрение, если конечно заказчик не дал вам карт-бланш на действия такого рода.
Возможно я не прав, но я стараюсь объективно смотреть на ситуацию. С одной стороны, не профессионал не сможет дать четкое определение тому, что он хочет получить, так как он не знает нюансов реализации того, что он задумал. Он может поверхностно описать и ткнуть пальцем в понравившийся дизайн. С другой стороны - разработчик хочет иметь документ, который регламентирует его работу и защищает его от новых хотелок клиента и "игр со шрифтами". Истина, как всегда, лежит по середине - работа делится на автономные модули, которые согласовываются и оплачиваются либо авансом, либо по факту выполнения. То что уже согласовано не может быть пересмотрено клиентом, кроме как за отдельную плату.
И еще такой психологический момент:
Когда клиенту выкатывается готовый продукт, у него возникает ощущение, что ему впаривают нечто сделанное по шаблону. Постоянный диалог с клиентом важен по той еще причине, что у него создается мнимое чувство того, что он контролирует процесс и стоит у руля. Соответственно, в случае каких либо недочетов, ему остается винить только себя, так как это он повелел сделать красную кнопку на зеленом фоне, несмотря на предупреждение разработчика о том, что обычно это плохая идея )
Назар Мокринский: еще вопрос немного не в тему)
А как обстоят дела с SimpleClever CMS?)
Искал в интернете инфу о скорости обработки запроса у разных CMS и наткнулся на вопрос на Тостере, где Вы рассказывали о своем творении , при этом приводя ссылку на SimpleCleverFramework (https://toster.ru/q/240249)
Почитал на гитхабе вводную часть информации и заинтересовался)
Дмитрий Ковальский: мы подбираемся ближе к истине)
Уже и ГОСТ становится вроде как ненужен (нахрена фрилансеру ТЗ по госту? Чтобы хранить в архиве рядом с ордерами на гарнитур генеральши Поповой?))
Дмитрий Ковальский: выше описал свой взгляд на такое явление как ТЗ)
Но вот что еще могу добавить)
Самому разработчику вот это вот все зачем?
Неужели ему самому удобно получать информацию с листа бумаги, чем из уст клиента, задавая те вопросы что его интересуют?
Заказ на создание ПО это такая вещь, которую люди делают достаточно редко и поэтому не обладают требуемыми навыками в изложении своей мысли на бумаге разом от начала и до конца (по сути это полностью построенная архитектура продукта, с указанием сколько пикселей должно быть расстояние между кнопками, сколько и каких цветов использовать в цветовой схеме и тому подобное, и все это требуется от неподготовленного человека)
Создается впечатление, что у разработчика стоит цель подловить клиента на его ошибке и исполнить все с точностью до наоборот, как хитрые джинны в сказках выполняют желания наивных обладателей волшебной лампы)
Цель разработчика сделать так, чтобы клиент остался доволен и порекомендовал его своим друзьям и знакомым. Если он не обнаруживает необходимую информацию в ТЗ, то его долг созвониться с клиентом и уточнить этот момент, а не действовать по принципу "все что не запрещено - то разрешено".
Следовательно, если общаться с клиентом в процессе работы всеравно придется, то зачем откладывать этот момент на потом, а не начинать разработку как раз с этого общения?
Разработчик - профессионал в своем деле. Какой нибудь парикмахер - профессионал в своем. Мы же не пишем ТЗ парикмахеру, где указываем сколько волос в сантиметрах и с какой стороны надо снять и какую технику стрижки при этом применять. Мы просто говорим - сделай чтоб было круто)
А все остальное это уже работа парикмахера - показать каталог, понять вкус клиента, и сделать свою работу профессионально)
ManWithBear: в этом и есть проблема ТЗ, что невозможно описать все досконально. Мне кажется более правильным итерационный подход. Сделал маленькую часть работы - показал, утвердили, оплатили и двигаемся дальше.
В противном случае мы получаем абсолютную незащищенность заказчика перед исполнителем. Надо мне кнопку сделать - а он ее картинкой например забабахал и говорит, мол в ТЗ об этом небыло ничего, значит делаю на свое усмотрение - сами виноваты что не указали этот момент. Клиент вообще не должен понимать все эти нюансы с заданиями. Он платит бабки и это его единственное задание, что он должен выполнить - предоставить бюджет. Все остальное исполнитель должен у него сам узнать, задавая правильные вопросы и показывая правильные макеты)
ManWithBear: теперь прочитал)
Но вопросов от этого меньше не стало)
Тоесть какой нибудь фрилансер в интернете, если я его попрошу написать мне лэндинг, потребует с меня вот такую вот простыню текста?)
