Ну не всегда.... Часть проектов под NDA. Часть собственно не особо покажешь. Предположим сделал я сайт: для посетителя это "типовой интернет магазин", а под капотом 100500 сервисов угадывающих по характеру кликания мыши пользователем зачем он сюда зашел, такого уровня что чат гпт - детская игрушка :D... Утрировано но тем не менее. А сколько "больших" студий с громадным портфолио, а коснешься их проекта - там тихий ужас.
На мой взгляд достаточно справедливая почасовая оплата с предоплатой. Т.е. заказчик может внести не большую предоплату, а там уже по своим "маркерам" решать - работать с данным исполнителем или нет... И тут, увы нет ни каких четких критериев как распознать хорошего и не проморгать плохого.
Не совсем. Это сотрудничество равноправное. И каждый лично для себя и для своих условий принимает допустимые критерии. Если у разработчика дофига заказов - он будет наращивать свои требования, если заказов нет - будет соглашаться на все что угодно... точно так же и заказчик.
Еще не забудьте дизайн заказать у дизайнера, который полиграфией занимается, а не сайтами... В макете может даже красивее будет (нет же ограничений вносимых всякими глупостями типа адаптивности и прочими... :D
Ну тут такой момент, что те же самые видео можно заливать во все сети. Единственный момент, который усложняет это (на реальном опыте): это для нельзяграма (для более такого привлекательного формата) приходится делать квадратный вариант видео и укладываться в 10 минут. (там конечно есть вариант и больше, но как то он меньше отклика давал - возможно дело ниши).. Так что из приведенного списка можно объединить несколько пунктов (и даже добавить в них)
Но тут другой момент: ваша ниша. Целевая аудитория такого блога, на мой взгляд, не является вашей целевой аудиторией (если цель получение заказов). Если же вы хотите заняться обучением - то вполне себе вариант.
То есть без ИИ было непонятно, о чем я пишу? 😂
Ну тогда вообще грусть)))
А чего тут грустить. Я такие тексты читаю по диагонали. На форум захожу не для разминки мозга, а скорее "отдохнуть" :) . Нафиг напрягаться в пассажи. Простой пример: при первом прочтении (первого сообщения темы) я решил, что ты за велосипеды, хотел было уже строчить текст на эту тему, да стал цитату создавать и увидел, что "диагональ чтения " прошла как то кривенько.
Можно вернуться и к теме "грамотный подход к решению задач" Т.е. вот излишки воды в описании проблематики - тоже мешают решения задач. Т.е. при описании задачи, даже для себя, мне кажется важно разделять сухое изложение проблематики и выводы. Это не дает так сильно остальным участникам процесса уйти в сторону.
Если речь (всего спича) про ТС создающего тему - может не хватать квалификации. При этом есть "какие ни какие познания" и начинает выдвигать предположения надеясь облегчить ответ, чтоб не напрягать излишне отвечающих.
Ну а далее:
"это интернет детка" (с) не мой - это тоже один моментов, который вносит свою лепту в подобные развития обсуждений в топиках: кто то решил, что все работы по анализу проведены и развивает заданный вектор, кто то просто зашел похоливарить, у кого то какой то момент обсуждения имеет отклик в собственных задачах - и он акцентировал уже на этом моменте.. Это еще "присыпается" солью: кто то скатился на личности и начинается междусобойчик.... Ну и потом уже кто то приходит, лень читать 100500 страницы, и отвечает на основе нескольких сообщений которые попали в поле зрения.
Как итог все оговоренные этапы решения задачи это дело исключительно ТСа, а форум лишь как источник дополнительной информации. Помощью, для форума в этом плане, было бы сознательное поведение всех участников (верится с трудом) и жесткая модерация - но это несколько смягчило бы, но не решило бы проблему.
Так же и про ИИ.. А есть ли реальный интерес разобраться в этом у большинства участников?
Да, перечитал еще раз, понял, что ты имеешь ввиду. Но этой агрегацией ты упрощаешь запросы, то есть ходишь за данными в одну таблицу, но начинаешь гонять по сети лишние данные и хранить дубли данных. Так себе вариант
В смысле лишние данные?
Ясно дело к с любому решением надо обдуманно подходить. Расставляем приоритеты для каждого выполнения скриптов (в т.ч. хит посетителя). В проблеме вынесенной ТС ом на обсуждение проблема именно с отдачей. Данные будут все те же самые хоть от нормализованной БД хоть нет.
Т.е. разница будет только в момент записи, но, вряд ли запись идет на хите посетителя и сразу тысячами записей. Даже на страницах (если таковые будут) где позволительно работать с "нормализованным" - опять же там не будет лишних данных. Конечно если не писать в выборках * вместо перечня необходимых полей... Но использование звездочек в селектах в общем случае это зло, за которое бьют по рукам. ИМХО.
Ты точно это имел ввиду? Не наоборот?
Нет. Именно "де". :)
При повышении быстродействия (на отдачу) это вполне себе вариант. Возможно, конечно, на этом проекте это не нужно - все же 5 гигов по современным меркам это не много.
Сделать кеш как таковой хоть на файлах хоть в памяти это не проблема. Самый главный вопрос при кешировании это определение инвалидация данных. Это хорошо когда контент практически статический, но когда есть динамика, то простое кеширование уже может потерять свою эффективность.
Как понимаю у ТС есть и достаточно динамические данные. Тут может потребоваться и кеширование не всей страницы, а страницы по частям. реализовать можно по разному, возможно более менее "простое" решение - подгрузка динамичных блоков на ajax - у которых будет свой кеш (отдельный от всей страницы). Который сбрасывать, на пример, не только по таймауту, но и при поступлении новых данных - тут уже зависит больше от деталей проекта.
Но кроме кеширования, конечно и с БД надо явно поработать. И тут может быть стоит задуматься и о денормализации, или периодической агрегации данных в отдельные таблицы (например по расписанию) - все сильно зависит от деталей проекта. Возможно, полезным будет использование представлений
Так же хорошим бы шагом было бы (но тут зависит от возможностей хостинга) было бы использование для статистических данных более подходящей СУБД. в частности ClickHouse
Ну и да, лучше озадачиться и перейти на php 8.* Не обязательно, как тут выше писали это про ООП, можно и в процедурном стиле. Это даст и увеличенное быстродействие и добавит безопасности.
Вообще я на фразу про налоговую написал :) Соответственно заявление и было в налоговую.
Или тут речь про налоговую штатов в случае когда адсенс автоматом налог списал?
Не. Я свои переносил(точнее они частично все уже там были - на всех площадках канал есть). Не подумал, что речь идет о чужих :)
