Саня Технадзор

Да надо.

Неважно на какой вид оплаты вы договорились - вы должны просто указать что то что принимает клиент в момент приемки означает что это он "забирает" в рабочем виде.

Тестировать надо вместе и по заранее согласованным сценариям - это путь к договоренностям.

Если клиент не хочет подписываться под конкретные сценарии - вы должны работать по-недельно. То есть - оплата за неделю, в течении недели находится баг, вы его чините, и так далее.

Для аргументов дам вам понимание - данные которые начинают двигаться в эксплуатируемой системы меняют состояние созданной системы.

То есть вы не имеете возможностей (ровно как и любой человек в этом мире) предвидеть все возможные варианты.

Итого это регулируется тестовым сценарием под который ставится подпись, на нем написано что все что в оговоренный сценарий не входит - в него не входит. Если надо будет проработать новый кейс - он будет для вас обоих новым кейсом, потому что не представлен в бумаге.

Используйте бумагу всегда вне зависимости от того как изначально договаривались - высылаете написанный сценарий и говорите - будет так, проверять по этому сценарию, если у вас есть комментарии по сценарию - вносите изменения.

Разумеется каждый набор тестов с оговоркой на каких девайсах проверяете.

Вы вступили на очень интересный путь который практически все кидают и не могут пройти, просто не хватает у людей сил - но он содержит свет в конце тоннеля - сценарий приемки передачи работы ориентируясь на результат, а не проваливаясь в постоянные доработки за свой счет просто потому что клиент это хочет добавить и "он так считает что это подразумевалось".

Телепаты же в отпуске.

Успехов.

У меня есть ценообразование которое работает так как вы описали, и клиенты за это платят.

Так как я даю ссылку и это на моем сайте - модераторы постоянно выпиливают эти ответы, я честно говоря немного этим возмущен, но вы знаете что делать.

UPD: Подробно об этом я рассказал на спарке https://spark.ru/startup/mjolnir/blog/32675/pravil...

Правильно гуглить - endless page

Научитесь решать проблемы без акцента на технологию - рекомендую изучить тематику по Системной инженерии.
В этом направлении вы всегда останетесь при любимом техническом инструменте (сами выбираете что необходимо) и будете решать задачи, контролируя и аргументируя техническую часть самостоятельно. Хороших технических директоров крайне мало, платят хорошо, и возьмут именно тех кто "решает" вопросы, путем успешного применения конкретных технологий и направляя персонал на решения которые бизнес крайне ценит.

Уходя в специализацию вы берете на себя риск вымирания инструмента (все уже за 10 лет сильно поменялось), не самого инструмента, а его ухода с рынка решений. Так что всегда лучше занимать позицию чуть более отвязанную от конкретного инструмента, системная инженерия даст направления куда думать.

Успехов.

Вот правильные вопросы люди пишут, я только подведу к ответу - составьте в экселе конкретную таблицу по пользователям / страницам / картинкам и их размерам, добавьте еще что-нибудь по вкусу и посмотрите что на что выходит.

Из цифр всегда просто сделать выводы о том какие вам нужны железки, какая архитектура этого всего понадобится, также вопросы по языкам / обработчикам, ведь если все сильно мощно по эксплуатации этого добра тогда вам и про кеш и про cdn думать нужно, и какая стратегия ваших действий (стратегия - последовательность задач которые вы решите чтобы достичь вашу цель).

Думать от цифр очень практично и удобно - большинство ответов перед глазами.

Крайне рекомендую использовать для этого гугл таблицы, потому что их встроенная автоматическая статистика (при клике справа снизу на значек explore) показывает сразу все виды срезов и отчетов и по техническим системам узкие места обнаруживаются очень быстро.

Узкие места - это найденные точки от которых вам нужно принимать решение как поступать.

А по существу - я храню в базе картинки которые добавляют пользователи через визуальный редактор, очень удобно копипаст делать, и просто в одном месте это "добро" держать, они у меня падают прямо с текстов в binary (это когда в img src="data:image/jpeg;base64....") - очень удобный кейс без заморочки аплоуда и поддеркжи того что накидают где у нас малый контроль.

Все остальные изображения относящиеся к контенту - лучше выносить и сразу в storage - любой, от s3 до dropbox, не важно, смысл в дальнейшем удобстве обслуживания - в его и бекапите, и разливаете по cdn если нужно, и что угодно делаете вне зависимости от кода.

Ну в общем все решения существуют не в позиции конкуренции друг с другом - а в позиции конкретного применения в зависимости от ваших целей, которые вы себе определяете из вашего контекста. Большинство решений крайне хороши сами по себе, применять нужно то что вам будет а) проще всего реализовать и поддерживать (не забывайте что вы с набором своих навыков тоже полноценная часть этой системы) б) что дешевле по времени и ресурсам решит вашу задачу (упрощенный ТРИЗ - идеальная функция та которая работает и не требует никакого ресурса).

Успехов!

Существует и много. На соседнем сайте работаю больше 5 лет. freelansim.ru

Ценник зависит только от тебя, понятно что ты не совсем четко понимаешь что именно это значит и как этим управлять - но все же зависит только от тебя и от того как ты научишься работать с ценами и клиентами.

Для начала нужно не боятся и просто начинать работать - все остальное появится без сильного напряга если ты работаешь. Успехов и не бойся - все получается, начни!

Всегда старайтесь смотреть на "старший" фреймворк откуда все это дело портируется с первого дня создания laravel. (в хорошем смысле без холиваров).

Долгое время в rails я просто выносил общую логику в модули, не знаю как сейчас конкретно это делается в php, но концептуально это просто все набор функциональных методов (не содержащих состояния) объединенных в неймспейс - фактически это может быть и класс любой.

В общем делается инклюд и пользуешься.

Говоря про рельсы в итоге там для этой функции появились концерны - что будет в laravel для этого неизвестно, но можно просто смело использовать функциональные классы. (функциональное программирование)

UPD собвстенно в рельсах для этого есть концерны, хелперы для другого - но в вашем случае хелперы помогут если не делать "свои" концерны как я указал.

Снова похожий вопрос, я тут уже как-то отвечал, но вот еще раз ссылка на пост полутора-годовалый может поймаешь уверенность - www.pavlyut.com/posts/freelance-is-good

Лучше поставьте тег не только яндекс но и modx.

Начать с просмотра логов на сайте - как у вас там выглядит визит яндекса.

Загружать все по возможности асинхронно, но это сильно зависит от контекста, так что подробнее можно посмотреть например тут https://css-tricks.com/thinking-async/

И придумать где и что воткнуть в твоем случае.

Непонял до конца что значит по высоте - что выравнивать align контента в столбце или сам столбец в ровень с чем-то или ...

Если читать буквально вопрос то по высоте и col это col vertical alignment https://getbootstrap.com/docs/4.0/layout/grid/#ali...

Если что-то другое то укажи на пункт доки из ссылки я сделаю пример если не понятно как применять.

Не боись

[хотел просто написать но не дает все вставить, так что сходите по ссылке там все я разложил на эту тему почти два года назад]

www.pavlyut.com/posts/freelance-is-good

Просто подпишитесь на твиттер https://twitter.com/jsunderhood и через пару недель у вас будет достаточное представление о современном хорошем фронтенде. Там же и вопросы задавайте.

Все комментаторы совершили одни и те же ошибки управления потому что, при всем уважении, скорее всего за эти ошибки (в стратегировании) они не платят из своего кармана.

На пальцах отвечаю на ваш вопрос:

1) По структуре - при проверки качества кода / решения / задачи / продукта / настройки сервера и так далее нужно проходить по списку (чеклист) критериев контроля качества - обычно они выглядят как списки определенных параметров которые может замерить третье лицо или сама система - формат проверяемого параметра прямо вот соответсвует / не соответсвует. На сколько процентов пройден чеклист - на столько процентов результат "качественный"
2) Почему ребята ошиблись - потому что стали приводить конкретные списки. Дело в том что у каждого проекта / сиутации / команды / набора компетенций - свои наборы таких чеклистов на разные ситуации. В больших командах сущесвтует основной чеклист который регламентирует CodeReview - и за него отвечает как правило тим лид - он его обновляет, развивает, обосновывает внесенные правила и следит за тем чтобы ПЕРЕД началом разработки все разработчики были ЗАРАНЕЕ ОЗНАКОМЛЕНЫ с этим порятком проверки качества, а все потому что:
3) Количество стайлгайдов и критериев в приципе существует огромное количество - и то как каждому в одной части света / компании удобно делать одно дело - не регламентирует ни разу что именно так же другому человеку в другой ситуации применять эти правила к своему контексту. В виде открытых стайлгайдов они существуют для накопления практик и навыков в первую очередь для их же развития (процесс формулировки наводит порядок в голове) а также дают возможность "на них конкретно" нанизать точечные ответы огромного сообщества людей, и получить те самые разные взгляды на ситуации, и по возможности опять же привести к общему знаменателю. Но это все мелочи жизни, а в вашем случае вы совершите серьезную ошибку если прямо сейчас возьметесь (примите на себя ответственность) проверять чужой код на предмет оценки, потому что:
4) Вас явно используют как внешнего эксперта на которого можно сослаться, от которого можно получить якобы аргументацию для давления на свою позицию при решении какой-то возникшей ситуации во взаимоотношениях клиент-разработчик на проекте куда вас приглашают за экспертизой.
Если вы, не предупредив, о том что "качество кода" начинается с декларации этого качества (в случае если речь идет о проверке этого внутреннего качества в рамках сотрудничества, а не самих задач которые поставлены перед создаваемой системой - фичесов) - любая ваша оценка будет недостоверна контексту ее применения (вы напишете про строки или еще что-то - а у человека будут либо взыскивать деньги / либо недоплатят за работу / или инкапсулируют в договоренности пост фактум за те же деньги работу над соотвествием определенным стилям - это все работа которая должна быть оплачена). Поэтому вот вам вилка ваших дейсвтий:

1) Если у вас просто просят менторства молодые коллеги - дайте им ссылку на гугл и ключевое словосочетание php style guide github
2) Если вас спрашивают (либо вы сами являетесь таким заказчиком который ищет за что зацепиться в коде чтобы продавить свою позицию) - нет критериев качества кода ДО начала работ подписанных на бумаге / пересланных по почте - никакие критерии не могут быть применены к текущим отношениям - только к следующей итерации за следующие деньги.
3) Если вы все же разработчик и вас попросили оценить код - донесите данную ситуацию до стадии корректного закрытия текущего этапа работ - но дальше предложите уже введение стайл гайда если оно того требует. Я полагаю что на самом деле нет. Дав сейчас ответ на вопрос в виде оценки качества кода вы сделаете только одно - абсолюно необоснованно дадите агрумент в явно перекошенном споре, и просто возьмете на себя еще один мешок кармогрязи которую будуете еще сколько-то положенного времени отрабатывать.

Подумайте хорошо на эту тему - придется выбрать свою сторону.

В "серьезном" тз должно быть следующие вещи:

1) Цели проекта которые будут решены при помощи проекта - тут ни слова о проекте. Тут те участники, из проблемы, и как они будут решены если продукт есть и работает успешно (ни слова о продукте тут!)
2) Задачи проекта - каким образом при помощи проекта будут достигаться цели. Нужно перечислить успешные состояния того, что описывает "успешность достижения цели".
3) Образ решения - сценарии, экраны, структуры данных. Иными словами ответ на вопрос "Как выглядит и работает успешный продукт".

Третий пункт желательно оставить на свое усмотрение и ответсвенность, а подписывать первые два. Именно образ решения вы формируете как специалист. Главное это зафиксировать задачу.

Подробнее тут - www.deppkind.com/product_requirements_document
Пример тут - files.deppkind.com/DemoofRequirementsDocument.pdf