Vicom

Выскажусь со стороны так сказать оскорбленной аудитории.
хлеб Ваш друзья програмисты никто не отнимает а скорее наоборот, рано или поздно, когда все ресурсы того же Мьюса иссякают а задачу возможно решить лишь встраивая JS или PHP коды начинаешь рыть форумы, и обращаться за помощью к подобным вам гуру. и как правило не бесплатно. но вот чего у адобовского конструктора не отнять так это мощнейшая визуализация. и именно адоб понял как стереть эту грань недопонимания между дизайнером и верстальщиком. скажу честно для меня темный лес все эти кракозябры а если недайбог часть кода хериться - да мне честно пол жизни не хватит что бы всего этого понять. а тем более изучить с нуля - Каждый занимается своим делом. и это огромноый плюс. Я проф дизайнер но именно с тем же Мьюсом мое сознание расширилось и большинство задач которые раньше мне приходилось объяснять вашему брату на пальцах пританцовывая, а после смериться что все равно не то как изначально задумывалось теперь я могу реализовать самостоятельно. И ЭТО ЗДОРОВО! спасибо за ваш тяжкий труд, ведь и те же веб конструкторы были бы сейчас недоступны без вашей кропотливой и как правило магической работы. у меня все.

Руководствуясь принципом KISS, может, просто начать писать через разделитель «категория.тип»:
image.png|image.jpg|image.gif|audio.mp3

Это поле в таблице у вас типа ENUM?

Проще запустить один скрипт, который выполняется "всегда" по циклу, а там уже в нём можно поставить задержку в секундах, если будет нужна.

Стопудово это какая-то тупая задача вообще крона не требующая, эти "секреты" задолбали, напиши нормально - "я не могу сообразить как делать правильно %определенный_функционал%, пришла идея делать неправильно, как сделать правильно?". Нет же, все пишут - "мои лыжи не едут по асфальту, подскажите как приделать к ним колесики и ракетный двигатель, для чего не скажу, это ВеликаяТайна".

Какая работа по душе, туда и идите. Если бы грузчики получали больше инженеров (а иногда так и есть), я бы все равно не пошел работать грузчиком потому что не люблю рутинную монотонную изнурительную работу. С другой стороны, кто-то не любит напрягать мозг - он идет грузчиком. Это ничего не значит, просто каждому свое. Из своего опыта добровольного и бесплатного опыта бета-тестера могу сказать, что это рутинное и неинтересное занятие, от которого сильно тянет в кроватку. Но есть прекрасные тестировщики, балдеющие от своей работы. Кто прав? Тот кто сделал для себя правильный выбор.

Зазорно не учиться и не искать знания.

Моё мнение, если тебя никто не ограничивает в стандартах выполнения ТЗ, то надо исходить из следующего:

1. Время.

2. Полезность ТЗ для разработчиков и прочих, но прежде всего для разработчиков.

2.1. Полезность это прежде всего описание бизнес-логики.

2.2. Прототип (делаю в Бальзаме).

2.3. Связи с подсистемами и интеграции.

2.4. Структуры данных и нагрузка.

Я пишу ТЗ и по ГОСТам и по корп. стандартам, но эффективней всего получается когда никто не ставит рамки.

Будут вопросы пиши в ЛС.

Примерно пару лет назад мне потребовалось структурировать базу контактов с клиентами. Изобрёл немного велосипедное решение для своих нужд. ТЗ по можно скачатьпо ссылке.
Как сейчас помню в то время на его составление у меня ушло часов 25-30 чистого времени. В начале я не знал какие инструменты использовать, чтобы исполнитель понял все нюансы правильно, поэтому многое переписывал. Так-же в процессе написания постоянно появлялись новые идеи, которые , как мне казалось не включить в ТЗ уже нельзя.
В результате после выхода первой версии программы, ушёл ещё месяц её на доработку. Пользовался ею я около полугода, всё это время собирал информацию, что можно было бы улучшить. Затем понабравшись опыта и знаний я написал новое ТЗ, которое составило 20 листов и ещё около десятка дополнительных файлов с картинками и таблицами. На составление второго ТЗ ушло около месяца.

Все зависит от того какими методологиями разработки Вы пользуетесь.

Чаще все это выглядит так:
1) Сначала накидываются пользовательские истории (user story), тот функционал, который Вы хотите иметь в программе. Они состоят из одного-двух предложений, кратко описывают одну единственную функцию. Например: хочу, чтобы была авторизация пользователей с подтверждением по email; хочу, чтобы у пользователя с ролью "админ" была собственная страничка для администрирования; и.д. В историях не должно быть никаких технических нюансов, только "хочу" заказчика (ну или Ваши).

2) Затем составляется карта (roadmap), в которой Вы описываете каждый шаг работы этой функции (пользовательской истории) с точки зрения пользователя:
1. Главная страница.
1.1 В правом верхнем углу находятся поля для аутентификации (для логина и пароля). Рядом находится кнопка "войти" и ссылка "зарегистрироваться".
1.2 При удачной аутентификации происходит переход на страницу ... и выводится сообщение "Добро пожаловать ..."

Потом на основе этой карты, делается прототипирование, выделяются задачи, если надо, разбиваются на более мелкие подзадачи.

Чтоб увидеть чужие ТЗ, полазите по чужому коду на гитхабе. Там очень часто люди описывают свой roadmap.

Просто спросить.

Привыкайте.

Для любого разработчика НЕПОСРЕДСТВЕННО работающего с заказчиком этап ПОСТАНОВКИ ЗАДАЧ, состоящий из довольно длительных переговоров/выяснений сути задачи - это НОРМА.

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

Если вы не госорган и не большая бюрократическая структура, то главное — пишите нормальным человеческим языком. Все бюрократизмы выжигать каленым железом. Не должно быть словосочетаний типа «наша система должна осущствлять функции по взаимодействию...».
Вы создаете продуктовое описание для того, чтобы объяснить концепцию другому человеку. Объяснять нужно человеческим языком.
Очень многие (90%) недооценивают важности этого и пишут продуктовые документы так, как будто это расшифровки съезда КПСС.

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

Его делают в техническом задании, которое пишут например в ворде или любом другом редакторе.

А куски кода и тех.задание обычно НЕ совмещают вместе, это разные документы.
Для описаний классов - UML, для разбиения тех.задания на конкретные таски - бэктрекеры, в которых солюшен дизайн может быть прописан прямо в тикетах.

Прошиваем роутер на openwrt, там создаем запись ads.youtube.com 127.0.0.1

Две недели? И весь проект от начала до текущего состояния - Ваш? OMG, я чего-то наверное не понимаю...

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

https://www.youtube.com/watch?v=z5WkDQVeYU4