Моя привычка победила. Всё-таки рабочий год удобнее начинать вместе с учебным, а не с календарным. Поэтому приглашаю проводить со мною лето и послушать рассказ про новый сезон.
Два года подряд на Деворкер мы выпускали планы о будущем развитии. В этом году на официальном канале выпуск задерживается. Поэтому пока поговорим о моём и немного Димином вкладе в проект здесь.
Мои скринкасты
Прошлой осень сбылась мечта — я подготовила и записала для Деворкера несколько скринкастов. Впечатления разнообразные. Это непривычно, иногда сложно, и похоже, что от моей молчаливой работы я скоро могу утратить навык устной речи.
Но с другой стороны — это была интересная работа. Я смогла понять, каково Диме было готовить и выпускать по одному видео в неделю-две. Мне казалось, что я с пятью видео справлюсь за месяц. Но когда начала продумывать детали, то поменяла и очередность выпуска эпизодов, и информацию в них. И вообще выпустила 7 видео за 14 недель.
Созданная заготовка не равна созданному материалу, будь то статья, или видео, или пост.
У нас много заготовок. Но каждую надо доработать. В некоторых не хватает опыта, а некоторые со временем становятся не актуальными.
Из планов было выпустить ещё несколько эпизодов про переработку личного блога ElisDN, моего (этого) блога, Деворкера и старого-нового менеджера проектов. Там хотела визуально показать макеты до/после, показать презентации и анализ исходных данных. Но колеблюсь. Виной тому две причины.
Первая — не хочется ради этой информации открывать свой собственный канал, так как видео относятся именно к нашим общим с Димой проектам. А если записывать на Деворкер, то у проекта получится тематика “программирование и не программирование”, то есть размывается основной контент.
Вторая — а кому это надо и будет ли полезно? И вообще, разве интересно смотреть, как устроена работа у других?
В общем пока с Димой не придумали, как преподнести этот материал на основном канале, поэтому мои заготовки пылятся без дела. Если вы можете дать рекомендации или просто сказать своё мнение по этой ситуации в комментариях, я буду очень благодарна!
Перезаливка старых эпизодов
Вторым огромным делом стала переобработка старых эпизодов Базы Знаний. За три года проб записей с разными настройками мы получили представление о том, какой звук нам нравится и как его добиться, расширились инструментами и техникой, увеличилось количество тренировочного материала.
На четвёртый год пришло время вернуться к началу проекта и посмотреть на него опытным взглядом. Это сделано было по двум причинам.
Первая — для подписчиков.
На первых эпизодах звук невозможно увеличить по громкости без примеси артефактов. Все сохранения-пересохранения, наложенные фильтры дают о себе знать.
Поэтому открываем каждый эпизод и всё перерабатываем. По времени — это почти как сделать новый эпизод, иногда получается даже дольше.
Бонусом идёт расстановка отсутствующих тайм-кодов. И также Дима при просмотре занимается редактурой. В основном эпизоды становятся короче на одну-две минуты. Но некоторые увеличиваются за счёт новой методики расстановки пауз.
К хорошим видео зрителям захочется возвращаться снова и снова.
Вторая причина — для себя.
У меня появилось внутреннее чувство ритма пауз. Даже обрабатывая в первый раз незнакомый эпизод, теперь их интуитивно расставляю. При финальной обработке остается только скорректировать.
Дима, пересматривая эпизоды, научился не только без сожаления их редактировать (что меня, кстати, иногда пугает :), но и отбирать по-настоящему важную для зрителей информацию. Освежил в памяти информацию, которая уже была рассказана.
Плюс от эпизода к эпизоду видно, как меняется его голос и манера изложения. На последних эпизодах голос звучит более объёмно, значит часовые распевки перед записью действительно помогают.
Отличие скринкастов от блога
За три года пришли к тому, что скринкасты и блоги — это всё-таки разные вещи. Блогера посмотрел один раз, потом остаётся ждать от него следующий контент. В скринкастах предполагается длительное взаимодействие зрителей с материалом. Поэтому скринкасты должны быть выше по качеству и всегда актуальны.
Все эпизоды, в которых показывается код, для нас оказалось перезаписывать нецелесообразно. Материал подавался хорошо, именно с технической стороны были проблемы. Теперь удалены лишние отступления, исправлен звук, насколько это было возможно. На мой взгляд, работа более чем полезная. Таким образом уже переобработано более 60 эпизодов, осталось около 40 штук самых сложных.
А вы часто пересматриваете наши эпизоды? Замечаете разницу в подаче материала, звуке, обработке?
Развитие проектов
Как и у всякого блога, у моего тоже происходит развитие. Одни темы уходят, другие занимают их место.
Я честно пыталась несколько раз браться за изучение языков программирования, собрала коллекцию книг, прошла курс Хекслета. Но не моё это. Поэтому и статей по программированию здесь нет и не будет.
Зато мне нравилось и нравится заниматься другим вещами. Для нас с Димой будет лучше, если мы будем развиваться в смежных областях, чем в одной. И каждому должно быть его дело по душе.
Сейчас в основном я выпускаю посты про новости одного проекта. Но публичных проектов больше. Поэтому блог не забрасываю, буду продолжать наполнять его по трём направлениям:
- новости четырёх проектов. Не только по Деворкеру, но и по другим.
- мое обучение. Это проектирование, прототипирование, разработка дизайна, менеджмент в рамках наших проектов.
- истории об обучении. Своеобразная болталка, чуть-чуть теории и много практики.
Конкретных планов по развитию не будет, так как планы можно построить только для той однообразной работы, в которой можно определить сроки и там минимум неизвестных.
В течение этого рабочего года все новые эпизоды и 40 оставшихся будут выпускаться и заменяться по мере их качественной обработки. В ближайшие два месяца есть желание заниматься творчеством. Поэтому работу над старыми эпизодами временно откладываю, и по мере возможностей и желания буду к ней возвращаться.
На Деворкере будут подведены свои итоги. Там помимо таких идеальных эпизодов хочется видеть больше жизни. Очень много готовимся, эпизоды получаются правильными. Но это не то, что хотелось бы видеть в течение долгих лет. Значит будем пробовать что-то другое.
Напишите, какие у вас планы по работе? Какие есть ожидания от развития нашего основного проекта?
Однозначно выкладывать на Деворкер! Не знаю, как остальным, но мне всегда интересно как устроен процесс у других, это одна из причин почему я вообще подписываюсь на такие проекты.
Отлично! Значит запишу скринкасты для Деворкера и не буду открывать свой канал))
Я попытаюсь высказать своё мнение по поводу Ваших проектов. Возможно оно поможет Вам. Но если что-то будет обидное или выглядящее как «Хэйт» — прошу не воспринимать это близко. При прочтении, помните, я пишу с целью улучшить проекты.
1. «Мои скринкасты»
1.1. Переработка проекта ElisDN и demo-project-manager.
Я часто смотрю коммиты Дмитрия в данном проекте. О том как он трансформируется. Это интересно, как старый Фреймворк немного взбодрить, но моё мнение — это не стоит целого обучения. Учить работать со старыми инструментов — только ради собственного удовольствия. Поэтому, я бы не стал публиковать обучение по трансформации данного проекта. Впервую очередь по причине того, что в сутках всего 24 часа. Можно просто написать об этом статью и не более. Что касается переработки менеджера проектов — тут тоже вопрос. С одной стороны это популярно. Но большая часть займёт Upgrade со старой версии на новую. Поэтому нового тут ничего не будет, как мне кажется. Тут нужно поразмыслить. Об этом я ещё напишу позже… Возможно я не понял тут Вашу мысль 🙂
1.2. Свой канал или deworker?
Тут однозначно, что deworker. Мне кажется, что deworker должен стремиться к тому, чтобы материал мог публиковать не только Дмитрий, а любой эксперт. Иначе Дмитрий не сможет один тянуть такую огромную работу. Вы начинаете помогать Дмитрию и это здорово. Надеюсь, что присоединиться в будущем ещё кто-то. По началу будет контент не очень, но он найдёт свою аудиторию. Возможно стоит ещё как-то разделить контент Дмитрия и Вас. Например, по Авторам. Либо по разделам.
1.3. Кому это будет полезно?
Как уже сказал выше — аудитория должна сформироваться. Причём своя. Скорее всего аудитории Дмитрия это будет не интересно, но это не значит что нужно всё завязывать на Дмитрие. Площадка должна быть агрегатор. Как Хабр. Если Ваш контент будет ценный — Аудитория сама найдёт Вас. Дмитрий же тоже когда-то начинал. Поэтому — начинайте!)
2. Перезаливка старого
Моё мнение — вы тут очень сильно заморочились. Перезаливать старые видео ради звука и картинки — сильная трата времени и оттягивание Вас от продвижения вперёд. Многие это отмечают. Я заметил даже то, что видео выходит про то как обновили ORM обновили PHP. То есть пока что-то переваливается проект уже устаревает и приходится писать видео о том как что-то обновляется. В рамках работы с обновлениями это было бы интересно, а в рамках проекта все ждут более значиме видео. Конечно, я понимаю Вашу педантичность, но я бы не стал заморачиваться над этим. Есть вещи, которые реально стоят перезаливки или переработки, но это точно не ради картинки и звука. Лично я не везде замечаю разницу до и после. Более того. Кто-то захочет посмотреть старую версию. Он сделал по ней себе какие-то заметки, а вы раз и всё поменяли) В итоге это может даже искажать. Перезаливать имеем смысл только «косяки». Остальное — это Ваша история. Архив. Взглянуть на старое имеет смысл только с целью опыта в будущем. В остальных случаях, как мне кажется, трата времени. Проще тогда уже версионировать как-то или же рассматривать отдельные темы, когда что-то меняется. Исходя из этого писал ещё на Деворкер, что возможно стоит делать декомпозицию видео. Я замечал, что некоторые блоггеры на frontend записывают видео на 1,5 часа на одном дыхании. Без всякого монтажа. Это получается на много быстрее. И даже о косяках никто не парится, потому что свежее и быстро. И подписчики увеличиваются. В наше время, когда всё быстро меняется, хочется чтобы и контент обучающий не отставал. А с перезаливкой можно погрязнуть в перезаливках 🙂 Извините, что так категорично…
3. Отличие скринкастов от блога
«За три года пришли к тому, что скринкасты и блоги — это всё-таки разные вещи. Блогера посмотрел один раз, потом остаётся ждать от него следующий контент. В скринкастах предполагается длительное взаимодействие зрителей с материалом. Поэтому скринкасты должны быть выше по качеству и всегда актуальны.»
Моё мнение это одинаковые вещи. Отличается лишь направленность блога (развлечение, обучение, юмор) и его способ донесения (видеоформат, аудиоформат, текстовый формат, вебинары, встречи, тренинги и тд). Если блог развлекательный, то от него, естественно, ждут только другое видео не пересматривая прошлые. А если блог обучающий вернутся к статье можно и написанной в 2008 году. Кстати, Вам контент нужно датировать. Это важно. Так как нужно понимать когда был опубликован материал.
«Все эпизоды, в которых показывается код, для нас оказалось перезаписывать нецелесообразно. Материал подавался хорошо, именно с технической стороны были проблемы. Теперь удалены лишние отступления, исправлен звук, насколько это было возможно.» Вот тут, как мне кажется, выстрел в ногу) К Дмитрию бегут не за хорошей картинкой или звуком и светом, а за знаниями. Если Вы заметите, то там где выступает Дмитрий всегда увеличенные просмотры и комментарии в виде вопросов, нежели другой приглашённый эксперт. Например, недавнее выступление Дмитрия на PHP Beer. Комментарии в основном к Дмитрию. И Вы можете заметить что картинка там не самая лучшая) Не заморачивайтесь!)) Код — в нашем случае самое главное и ещё главное как его объясняют. Дмитрий хорошо доносит информация. А какая там картинка — да хоть черно-белая, хоть на телефон записано — я всё равно посмотрю Дмитрия. И реально смотрю выступления Дмитрия за 2016 год, когда картинка была по сравнению с текущим плохая. Вы уже набили руку делать ещё и красивую картинку. Но не стоит прямо сильно заморачиваться над этим. Раз настроили и идём дальше. Чем меньше тратите времени на монтаж тем больше будет контента, а это, в свою очередь, привлечёт больше зрителей. Когда способны будете нанять штат — тогда и займётесь оттаиванием мастерства. Возможно я тут смотрю со своей колокольни. Предлагаю выложить опрос в канале с вопросом «Почему вы смотрите наши скринкасты»: Хороший контент, хорошая картинка, хороший звук, хорошая подача и. т д. Я, думаю, что большинство выберут контент) Главное не делать возможность выбора всего. Проголосуют за всё. Кстати собирать обратную связь через опросы хорошая тема. Вы тогда будете чётко понимать что нужно вашей аудитории. Например, если бы выложили опрос про переписывание скринкастов или запись новых — думаю, что выбрали бы новые)
4. «Развитие проектов»
Моё мнение Вам, возможно и не нужно пытаться повторять Дмитрия. Главное, чтобы глаз горел. Только тогда у вас будет стремление и мотивация. Вы сейчас выпускаете новости о проектах. А почему не опубликовать это на Deworker? Было бы полезно, а не только публиковать новости о новом скринкасте. Рубрик может быть много. Да и в целом можно устраивать дайджест новостей за неделю) С этим у вас бы получилось, думаю) В своё время я сделал группу Вконтакте с 0 до 12000 подписчиков. И всё без накруток. Главное чувствовать аудиторию. Давать ей что нужно. Взаимодействовать с ней. И не ограничиваться только скринкастами. Можно просто поделиться новостью, что вышла новая версия PHP, Symfony и что в нововведениях важного.
Надеюсь по переписыванию скринкастов услышали) Теперь хочу не прокомментировать, а поделиться своим видением по Deworker.Pro Как уже говорил ранее, на вашу площадку нужно привлекать других Авторов контента. Тогда это будет жить и развиваться даже без участия Дмитрия. Дмитрий может просто модерировать и отсеивать что не нужно. Но за ваш период наверняка есть люди которые выросли и хотели бы тоже чем-то поделиться. Почему вы не предложите им это? Если у них есть такая потребность — они в любом случае будут её делать. Только могли бы делать это не в своём блоге, а на вашей платформе. Оплата за просмотры, например) Как на хабре. Ведь это очень хорошая идея. Подумайте)
Здравствуйте, коллега.
Спорить не буду. Отвечаю, чтобы подчеркнуть факт, что люди разные и их потребности тоже.
Благодарю, что подняли важные вопросы.
> Я заметил даже то, что видео выходит про то как обновили ORM обновили PHP. То есть пока что-то >переваливается проект уже устаревает и приходится писать видео о том как что-то обновляется.
Это нормально. Программист этим занимается регулярно в своей практике.
И знать какие особенности ждут при обновлении пакетов вендором — важно.
>Я замечал, что некоторые блоггеры на frontend записывают видео на 1,5 часа на одном дыхании. Без >всякого монтажа. Это получается на много быстрее. И даже о косяках никто не парится, потому что > свежее и быстро
В этом и ужас. Так можно записывать болтологию.
Но сложный для усвоения учебный материал, да еще с кодом, нельзя.
Так и жизни не хватит многократно пересматривать часовые стримы, ища нужную информацию.
Раннюю серию скринкастов Дмитрия (микрофрейворк SLIM) я так и не смог посмотреть всю от начала до конца. Именно по причине громадных эпизодов и слабой структурированности.
>Кстати, Вам контент нужно датировать. Это важно.
>Так как нужно понимать когда был опубликован материал.
Согласен, это важно
> А какая там картинка — да хоть черно-белая, хоть на телефон записано — я всё равно посмотрю Дмитрия
Если каст «за жизнь» — да. Если профессиональный технический материал, требующий максимальной концентрации внимания на новых сложных вещах — нет, здоровья не хватит.
>Да и в целом можно устраивать дайджест новостей за неделю) С этим у вас бы получилось, думаю)
>Можно просто поделиться новостью, что вышла новая версия PHP, Symfony и что в нововведениях важного.
Дайджесты — вещь полезная. Но о своих событиях.
О том что вышел PHP 8.2 — можно проичитать где угодно.
Можно превратить ресурс в СМИ — но тогда он потеряется. ИТ-сми и информационого мусора — их много в интернете.
А что есть у Дмитрия — нет пока нигде:
— постоянно обновляемый проф материал по программированию (не для начинающих и не курсы). Максимально приближенный к практической разработке.
— подача, позволяющая этот материал переварить человеку со средними способностями.
На этом преимуществе и стоит концентрироваться, добавляя очевидно недостающие вещи (время публикации, теги и пр)
ИМХО.
ПС: интересно, есть ли в этом блоге какое то форматирование текста поста ..?
Здравствуйте, коллега) Я не против. Тоже отвечу. Очень рад, что немного оживим блог Юлии))
> Спорить не буду. Отвечаю, чтобы подчеркнуть факт, что люди разные и их потребности тоже.
Благодарю, что подняли важные вопросы.
Абсолютно согласен. Поэтому я высказывал своё видение, а не общее. Чтобы сделать вывод — нужно обладать полной картиной, которая есть только у Дмитрия и Юлии. Прочитав наши комментарии они увидят две разные точки зрения и сделают свои выводы)
> обновили ORM обновили PHP … Это нормально. Программист этим занимается регулярно в своей практике. И знать какие особенности ждут при обновлении пакетов вендором — важно.
Если программист занимается этим регулярно, то зачем тогда тем более об этом записывать видео) Всё таки я считаю, что видео у Дмитрия не для новиков, и в этом Вы со мной согласны. А если это так, то программист не новичок уж точно должен знать что его ждет при обновлении пакетов, как решать конфликты, что делать с заброшенными репозиториями, каким способом подменить реализацию в вендор, что делать при обнаружении ошибок и так далее… Если программист не может сам это сделать, то смотреть уроки Дмитрия для него будет крайне сложно. Нужно учиться решать эти вопросы самому, а не копировать их по видео. Все ситуации и обстоятельства по обновлению не изложить, тем более в демо проекте с качественно подобранными библиотеками. Что сложного обновить ту же ORM Doctrine которая очень популярна. Даже если возникнут проблемы — решение уже есть в интернете. Другое дело когда какой-то легаси код с непонятными зависимостями с заброшенными библиотеками. Тут уже просится отдельная тематика скринкастов по такие обновления. Так же, я ни разу не видел миграции данных действующего проекта в видео Дмитрия. Это же не значит, что вы в продакшене применяете миграции, которые удаляют данные). Хотя тема миграций на много серьёзнее, чем обновление зависимостей. При обновлении зависимостей у вас либо возникнут ошибки, которые вам не дадут двигаться дальше, либо всё обновится успешно. Если запускать composer update каждую неделю — проблем быть не должно. А вот когда проект уже живой и нужно мигрировать данные из одного модуля в другой по событиям — это уже сложнее и требует большего внимания. Можно не правильно мигрировать и потерять кучу данных. Поэтому я считаю тему обновлений не особо острой если библиотеки в проекте подобраны с умом. Чаще всего проблемы возникают в своём монолите, где нет чётких правил. Вот там и приходится иногда просто написать рядом модуль и мигрировать данные, либо транлировать в новый модуль. Хотя я не могу не согласиться, что пара таких видео для понимания нужно иметь) Это очень полезно. Не все знают всех фишек. Да и есть действительно сложные обновления только потому что проект не поддерживался или на него забивали, в том числе и в подборе зависимостей…
> В этом и ужас. Так можно записывать болтологию.
Но сложный для усвоения учебный материал, да еще с кодом, нельзя.
Так и жизни не хватит многократно пересматривать часовые стримы, ища нужную информацию.
Вы уже изначально сделали вывод даже не видев даже видео о котором я говорю. Возможно Вам попадались видео с болтовнёй. Но я говорю о хорошем примере. Автор за 1,5 часа не обрезал видео (либо это не заметно) и всё было по делу. Всё ценное. Скринкасты Дмитрия смотрю регулярно и у меня есть с чем сравнить. Единственное что отличает то видео от видео Дмитрия — это детали. Дмитрий старается разобраться в вопросе полностью. Сделать код по всем законам. Все названные переменные и комиты будут осмысленными. И это всё отнимает много времени. На фронте всё быстро меняется и привыкли через 3 года выкинуть дизайн/код и написать с нуля. Поэтому не сильно заморачиваются. Хотя есть и хорошие примеры. Но я же всё таки говорил о том, что не нужно тратить время на идеальную картинку и проработку Мега звука. Я сам монтировал много видео. И я знаю сколько времени это занимает. Более того любая обработка или эффект добавляет время на рендеринг данного видео, а так же увеличивает его вес. И в зависимости от эффектов видео может ОЧЕНь долго рендерится, что тоже увеличивает время частоты публикации видео. А если ещё компьютер слабенький, то иногда даже желание отпадает что-то монтировать. При этом опустить планку может уже восприняться как ухудшение качества. Поэтому тут можно попасть в свою же ловушку.
> Раннюю серию скринкастов Дмитрия (микрофрейворк SLIM) я так и не смог посмотреть всю от начала до конца. Именно по причине громадных эпизодов и слабой структурированности.
Всё зависит от степени усваивания. Я смотрю все видео Дмитрия на максимальной скорости. (Видел ниже что Вы делаете так же) и давно уже всё пересмотрел) В ожидании новых… Часто мониторю репозитории на Github всех проектов Дмитрия и уже даже знаю чуть ли не по строкам где что написано) Иногда привожу, в качестве примера, код Дмитрия отвечая на вопросы Хабр Q&A. Более того, стараюсь идти немного впереди. Самостоятельно ищу информацию и изучаю. Смотря на план Дмитрия и к публикации видео я уже что-то попрактику и изучу. А затем сравниваю свои результаты с подходами Дмитрия. Например, последнее видео про сериализацию у меня по коду получилось примерно то же, что у Дмитрия. Отличает лишь то, что я делаю на Symfony и у меня вместо Middleware — Подписчики. И плюс я в серализатор Symfony передаю ContextBuilder, а не просто массив с константами. Так, мне кажется чуть лучше и в то же время по-своему. Так же подписан на различные ресурсы и постоянно слежу за новостями. Мне кажется это то, к чему и нужно стремиться — к самостоятельности. Тогда у Вас выработается своё видение и Вы сможете принимать свои решения по проекту, а так же будете понимать где и что лучше. Ни в коем случае не упрекаю Вас. Понимаю, что у всех свои приоритеты и своя загруженность по времени. У кого-то его больше, у кого-то его меньше. Я готов смотреть часовые стримы и находить в них стоящее. Естественно, я не говорю о том, что смотрю все видео подряд. Фильтр никто не отменял) Ну и так же я не предлагал записывать все видео в виде 4-х часового стрима. Это неактуально. Этим высказыванием я пытался донести то, что видео можно записывать так, чтобы было меньше монтажа. Это, в свою очередь, позволит сократить время Дмитрию на поиск материала, его проработку и увеличит частоту. Опять же я говорю, что это не значит, что Дмитрий станет плохо доносить материал. Так же это не значит, что я предлагаю полностью забить на монтаж. Но какие-то то видео можно было выкладывать без монтажа и только стоящие или важные обрабатывать. Если вы посмотрите прямой стрим Дмитрия вы не сильно заметите разницу между монтажом и стримом по качеству. Мне кажется, что Дмитрий уже имеет хороший опыт и подготовку, что позволит даже уйти от различных речевых косяков, которые обычно убирают в монтаже.
> Если каст «за жизнь» — да. Если профессиональный технический материал, требующий максимальной концентрации внимания на новых сложных вещах — нет, здоровья не хватит.
Я же не сказал, что нужно выкинуть всю аппаратуру имеющаяся в руках наших Экспертов) Звук, записанный на профессиональный микрофон сильно не изменится, если его не обработать. От того что его не обработают не появятся на фоне видео визги детей)) Я имею 9 лет музыкального образования и имея хороший звук дома — я могу услышать разницу в звуковой дорожке. Но большинство смотрят с простыми колонками или наушниками типа AirPods. Хоть они и хорошие, но разницу по качеству мало кто заметит) Ещё раз предлагаю для сравнения посмотрите как Дмитрий проводил прямую трансляцию в 2021 году: https://deworker.pro/blog/stream-season-2021 Вы слышите здесь плохой звук? Или картинка плохая?) Я думаю, поняли о чём я)
> Дайджесты — вещь полезная. Но о своих событиях.
О том что вышел PHP 8.2 — можно проичитать где угодно.
Можно превратить ресурс в СМИ — но тогда он потеряется. ИТ-сми и информационого мусора — их много в интернете.
То есть посмотреть как обновляют код с 8.0 на 8.1 Вам интересно, а новость об этом не инверсно. Ведь об обновлении пакетов в Vendor и PHP тоже можно почитать где угодно…) Я не говорю, что сейчас нужно кидать всё и писать типичные посты или куда хуже повторять чужие. Юлия хочет найти что-то своё, поэтому перечислил варианты именно для неё, а не Дмитрия. У него и так много работы и планов. Кроме того, уже есть третий дайджест https://deworker.pro/blog/digest-3, если Вы не заметили…)
>А что есть у Дмитрия — нет пока нигде:
— постоянно обновляемый проф материал по программированию (не для начинающих и не курсы). Максимально приближенный к практической разработке.
— подача, позволяющая этот материал переварить человеку со средними способностями.
С этим сложно поспорить. Дмитрий хороший учитель и ещё раз говорю ему спасибо за его труды. Такой фундаментальный подход действительно напоминает больше университет. Надеюсь, что мы можем закончить на позитивной ноте, поблагодарив ещё раз Дмитрия и Юлию) Надеюсь, Вы присоединяетесь к моим благодарностям, хоть и где-то возникают разногласия. Удачи Вам в программировании и образовании!)
> Я сам монтировал много видео. И я знаю сколько времени это занимает. Более того любая обработка или эффект добавляет время на рендеринг данного видео, а так же увеличивает его вес. И в зависимости от эффектов видео может ОЧЕНь долго рендерится.
В отличие от обычных видео с камеры легковесные скринкасты спокойно просматриваются в редакторе в реальном времени. Особенно если разбить проект на получасовые части. И при экспорте часовой проект рендерится всего десять минут.
> В отличие от обычных видео с камеры легковесные скринкасты спокойно просматриваются в редакторе в реальном времени. Особенно если разбить проект на получасовые части. И при экспорте часовой проект рендерится всего десять минут.
В любом случае нужно стремиться к тому, чтобы на видео накладывать минимум обработки, в том числе видео. Но здесь, как я понял, не возникает такой проблемы. Ну что ж. Тогда это здорово) Именно к этому нужно стремиться. Для этого и приобретается оборудование свет, звук, микшер, чтобы монтаж был в итоге только обрезка оговорок. Отлично!
> Звук, записанный на профессиональный микрофон сильно не изменится, если его не обработать.
В том и смысл, что по хронологии скринкастов по Slim профессиональный микрофон и пульт у нас появились не сразу, а только к 55-ому эпизоду:
1..33 — Китайский USB-микрофон с шумом и писком
34..43 — Электретный микрофон и аудиоинтерфейс
43..54 — Профессиональный микрофон и аудиоинтерфейс
55..72 — Профессиональный микрофон и профессиональный аудиопроцессор
и раньше мы каждый раз экспериментировали с настройками. В итоге первые 54 эпизода оказались записаны вразноброд с разной громкостью и шумом и смонтированы в разном темпе. Поэтому вполне логично теперь переоткрыть все проекты и привести их к одному виду.
> В том и смысл, что по хронологии скринкастов по Slim профессиональный микрофон и пульт у нас появились не сразу, а только к 55-ому эпизоду
Теперь понял что имеется в виду под «переписыванием». Мне показалось, что Вы планируете постоянно перезаписывать каждый скринкаст время от времени только потому, что Ваше качество выросло. Главное, чтобы это не вошло в практику на постоянной основе ко всем скринкастам)
> и раньше мы каждый раз экспериментировали с настройками. В итоге первые 54 эпизода оказались записаны вразноброд с разной громкостью и шумом и смонтированы в разном темпе. Поэтому вполне логично теперь переоткрыть все проекты и привести их к одному виду.
Вот тут, моё личное мнение, разный темп кажется сомнительным критерием для перезаписывания) Вы всё таки скринкасты записываете не на одном дыхании. Вы делаете это в разное время, разные дни. У вас может меняться интонация, стрижка волос, голос, настроение… Слишком заморочено, как мне кажется. Вот этого критерия я бы избегал. Между видео может различаться голос, громкость, темп. Я всегда Вас смотрю на 2 скорости. Если Вы будете говорить чуть быстрее — я просто уменьшу скорость. На счёт шума тоже уже писал. Этот шум могут некоторые вообще не замечать. В любом случае Вам виднее лучше. Я просто высказываю своё мнение. Возможно, кто-то жаловался на это массово, а я говорю что это «фигня». Но я бы попросил Вашу аудиторию дать обратную связь по этому поводу. Хотя бы в виде опроса. И Вы сами всё поймёте. Сможете сделать вывод. У нас с Вами это может быть субъективное мнение. Особенно у меня…
> Но какие-то то видео можно было выкладывать без монтажа и только стоящие или важные обрабатывать. Если вы посмотрите прямой стрим Дмитрия вы не сильно заметите разницу между монтажом и стримом по качеству. Мне кажется, что Дмитрий уже имеет хороший опыт и подготовку, что позволит даже уйти от различных речевых косяков, которые обычно убирают в монтаже.
Вы под обработкой подразумеваете сам звук и эффекты, а мы говорим про речь и подачу.
На стриме именно болтологическое видео, где можно включить слайд и рассказывать анекдоты. С кодом же ситуация другая. Там после каждого предложения или абзаца нужно переключаться на сценарий или репозиторий и копировать следующий фрагмент кода.
С кодом без монтажа получаем три минуты суеты и мусора:
“Что там дальше… Ща посмотрю в черновик… Чтобы это сделать нам надо… Так… Переключаю коммит… Ага… Ctrl+C. В контроллер надо добавить такой код. Ctrl+V. Потом надо зайти в конф… В горле запершило… Кхе-кхе… Потом надо зайти в конфиг и туда вписать… Ой, не то скопировал… Ctrl+C… Такой код… Ctrl+V. Теперь тесты должны пройти. Проверим. Запускаем… Ждём… Ой, что-то отвалилось. Посмотрим в логах… А, точно. Ща исправим. На улице скорая помощь визжит. Подождём пока. Ждём… Теперь запустим… Ждём… Теперь проходят. Теперь посмотрим в браузере. Пусто. Забыли фикстуры. Применим. Обновим. Теперь видно. Всё, работает!”
С дублями (проговорить предложение ещё раз, если в первый раз не получилось) и монтажом (вырезать все переключения и ожидания) получаем десять секунд чистого материала:
“Чтобы это сделать нам надо в контроллер добавить такой код и в конфиг вписать такой код. Теперь запускаем тесты и всё работает. И видим результат в браузере.”
Первый вариант более “живой” и душевный, но много мусора и “воды”. А второй более информативный.
> Вы под обработкой подразумеваете сам звук и эффекты, а мы говорим про речь и подачу.
Нет, Я не подразумеваю это. Юлия сама написала в посте две причины. И одна из них звучит так: «На первых эпизодах звук невозможно увеличить по громкости без примеси артефактов. Все сохранения-пересохранения, наложенные фильтры дают о себе знать.» А с учётом слов Юлии «По времени — это почти как сделать новый эпизод, иногда получается даже дольше.», то я и написал — может не стоит того) Но тут решать Вам) Я могу чего-то не знать.
> На стриме именно болтологическое видео, где можно включить слайд и рассказывать анекдоты.
Стрим привёл в пример как раз с точки зрения картинки и звука, а не с точки зрения полезности. Естественно, что тут информации мало. Хотя можете взять на вооружение — в стримеры тоже есть интересные моменты, которые можно обрезать и залить отдельным видео)
> С кодом без монтажа получаем три минуты суеты и мусора
Это, естественно, нужно убирать!) Про это у меня и речи ВООБЩЕ не шло… Это должна быть практически единственная цель монтажа — вырезать не нужное или заменить ошибки. Более того видео можно записывать даже с какими-то комментариями для монтажа. Я думаю так вы и делаете) Минимизировать монтаж в этом случае помогает только написанный тест, который просто читается. Но это занимает много времени. Возможно и так Вы тоже делаете. Тут стоит выбирать что дольше.
> С дублями (проговорить предложение ещё раз, если в первый раз не получилось) и монтажом (вырезать все переключения и ожидания) получаем десять секунд чистого материала
Это помню. Вы это говорили на стриме или писали где-то в блоге. В прочем как и выше — это должна быть основная цель монтажа.
> Первый вариант более “живой” и душевный, но много мусора и “воды”. А второй более информативный.
Согласен!) Но перезаписываете же Вы не по этой причине. Вы же уже выпустили видео, которые были обрезаны от всего подобного….
>То есть посмотреть как обновляют код с 8.0 на 8.1 Вам интересно, а новость об этом не инверсно.
> обновили ORM обновили PHP … Это нормально.
>Программист этим занимается регулярно в своей практике. И знать какие особенности ждут при обновлении пакетов вендором — важно.
:))
Максим, когда я говорил про обновления ORM/PHP, я конечно не имел в ввиду работу с композером — для этого уроки не нужны для большинства студентов.
Я вот про что:
например, когда доктрина меняет версию, она депрекейтит кучу методов, которые используются в её конфигурации.
И когда после обновления — не взлетает.
А в проекте Дмитрия — конфигурация симфониевсеих пакетов весьма кастомная. И чтобы запустить ее с новыми фишками — копипасты примеров с сайта вендора недостаточно. Тут надо лезть в код вендора и подглядывать, как оно работает.
В таких частных случаях и StackOverflow не помогает.
Если у студента еще нет глубокого опыта с данным пакетом — это интересное мероприятие может сбить с толку и сильно затянуться.
В этом случае, уроки Дмитрия по переконфигурирования обновленного пакета — просто спасение.
> например, когда доктрина меняет версию, она депрекейтит кучу методов, которые используются в её конфигурации.
И когда после обновления — не взлетает.
Вам в консоли это всё показывается. А что изменилось и как теперь использовать можно почитать документацию по обновлению. Иногда и вовсе понятно по сообщению в депрекейте как теперь использовать. Более того есть rector, который переведёт вам Symfony, Doctrine, Unit test PHP и многое другое одной командой. Вам только нужно посмотреть эти изменения и закомитиь)
> А в проекте Дмитрия — конфигурация симфониевсеих пакетов весьма кастомная. И чтобы запустить ее с новыми фишками — копипасты примеров с сайта вендора недостаточно. Тут надо лезть в код вендора и подглядывать, как оно работает.
В таких частных случаях и StackOverflow не помогает.
> Если у студента еще нет глубокого опыта с данным пакетом — это интересное мероприятие может сбить с толку и сильно затянуться.
> В этом случае, уроки Дмитрия по переконфигурирования обновленного пакета — просто спасение.
Не используйте тогда кастомную настройку. Для Symfony всё настраивается довольно просто и миграция той же ORM зачастую внуьренность фреймфорка. Но если и что-то изменится достаточно посмотреть доку. Конечно, это касается не всех пакетов php. Какие-то вам придётся подумать как интегрировать и мигрировать на новую версию. У меня больше вопрос возникает тогда другой — как вы настраиваете другие библиотеки и что будете делать без Дмитрия. Ведь каждый раз ему писать в комментариях о своей проблеме — тоже как-то не очень хорошо, как мне кажется. Нужно учится самостоятельности. О чем я вам пишу каждый коммент. Если не готовы к Slim, то возьмите Symfony. Там многое проще и есть куча готовых бандлов. Ещё могу посоветовать смотреть не только вендор, но и тесты. В них можно много найти ответов как что-то работает и используется.
> В этом и ужас. Так можно записывать болтологию. Но сложный для усвоения учебный материал, да еще с кодом, нельзя.
> Так и жизни не хватит многократно пересматривать часовые стримы, ища нужную информацию.
Согласны, поэтому материал стали разделять и обрабатывать.
> Дайджесты — вещь полезная. Но о своих событиях.
> О том что вышел PHP 8.2 — можно проичитать где угодно.
Да, дайджесты можем выпускать только о своих событиях. Профессиональные новости можно прочитать во всех пабликах. Тратить силы на их подборку не хочется и времени нет.
Наш дайджест может выходить не чаще 1 раза в 3-6 месяцев, когда стоящих новостей на проекте наберётся больше. О пустяках не пишем. Не тратим ни своё время, ни время подписчиков.
> Есть вещи, которые реально стоят перезаливки или переработки, но это точно не ради картинки и звука.
Вы говорите с точки зрения зрителя, который уже давно на сайте и которому пересматривать старые видео уже неинтересно. Но вы не учитываете новых посетителей, которые начинают смотреть всё с самого первого эпизода. А там трэш с невыровненной громкостью, бубнежом, дыханием и чавканием. Сказать им “Потерпите пока так, а потом с 30-го эпизода мы начали громкость выравнивать и речь выправлять” не очень гуманно.
> Вы говорите с точки зрения зрителя, который уже давно на сайте и которому пересматривать старые видео уже неинтересно. Но вы не учитываете новых посетителей, которые начинают смотреть всё с самого первого эпизода. А там трэш с невыровненной громкостью, бубнежом, дыханием и чавканием. Сказать им “Потерпите пока так, а потом с 30-го эпизода мы начали громкость выравнивать и речь выправлять” не очень гуманно.
Вы ошибаетесь. Я говорю о популярности видео. Тут не важно новичок или старичок. Популярность — это чаще всего какая-то тема, которая «зашла» и которая волнует многих. Популярность на ютубе оценивается лаками и просмотрами. Какие-то видео набирают 1 млн просмотров и оно популярно, а какие-то 10 тыс и оно не популярно. Вам можно ввести что-то подобное. Либо у вас уже есть «избранное» на deworker для комментариев. Можно сделать для Видео подобное и смотреть что чаще добавляют в избранное.
По поводу того, что старички не смотрят старые видео тоже ошибочное. Ещё как смотрят. Владимир Перепеченко в этой статье в комментариях об этом тоже говорит. Есть видео, которые я пересматриваю несколько раз. Причем даже спустя долгое время — год или два.
Ради новых посетителей стоит рассматривать другой случай — это изменение подходов, инструментов или изменения языка. Например, если новичок зайдёт на скринкаст, в котором рассматривается php 5.6, естественно он может не понять материал или понять его не так. Вот с этой целью тоже имеет смысл перезаписывать. Но всё же ещё раз напишу, что такие материалы нужно как-то версионировать. Кто-то может вернутся из старичков за старым материлом и увидеть там новую версию. Грубо говоря следовать семантическому версионированию. Если исправляются какие-то баги, звук ошибка — это не особо важно с точки зрения изменений. Просто будет приятно слушать. Но если там поменялся код, Таймкоды — тут я бы выложил это в виде новой версии. Я знаю, что некоторые видео, не смотря на то что есть тамйкоды, люди себе помечают важные темы в блокнот. И когда он зайдёт в перезаписанное видео у него произойдёт несоответствие. Поэтому «обратную совместимость» тоже нужно учитывать при переписывании. Иначе получается старички страдают от новичков)
В любом случае я давал вам обратную связь. Возможно моё мнение — не мнение большинства или вразрез противоречат вашему. Однако указывание авторов на канале уже добавлено. Это здорово) Возможно когда-то сможет и кто-то другой записывать видео здесь и deworker станет агрегатором разных авторов) Мне кажется, что стремиться нужно к этому.
> Но не стоит прямо сильно заморачиваться над этим. Раз настроили и идём дальше.
Как раз за это время пришли к упрощению работы. Теперь звук записываем сразу идеальный, обработанный аудиопроцессором. И речь проговариваем целыми предложениями. При монтаже остаётся только убрать неудачные дубли и вычистить вздохи.
> Чем меньше тратите времени на монтаж тем больше будет контента, а это, в свою очередь, привлечёт больше зрителей.
Вы преувеличиваете влияние монтажа на затраты времени. Весь монтаж с рутиной занимает один или полтора дня, но автор (Дмитрий) там просматривает материал всего один или два раза, чтобы проверить сюжет и расставить тайм-коды.
На обдумывание, подготовку и запись старой серии про HTTP-фреймворк без монтажа у меня ушёл год. С монтажом ушло бы на неделю больше. Основное время занимает подготовка, структурирование, программирование и запись, а не монтаж.
> Как раз за это время пришли к упрощению работы. Теперь звук записываем сразу идеальный, обработанный аудиопроцессором. И речь проговариваем целыми предложениями. При монтаже остаётся только убрать неудачные дубли и вычистить вздохи.
Отлично! Значит Вы и так уже пришли к этому. Именно к этому и нужно стремиться. Просто через время может возникнуть желание переписать всё снова, потому что вы теперь и умеете делать 3D модели, а в прошлах скринкастах вы показывали всё на 2D моделях… Я об этом) Ваши навыки всегда растут и это не должно быть причиной переписывания старых работ, если только они не ценные.
> Вы преувеличиваете влияние монтажа на затраты времени. Весь монтаж с рутиной занимает один или полтора дня, но автор (Дмитрий) там просматривает материал всего один или два раза, чтобы проверить сюжет и расставить тайм-коды.
Однако это тоже время. Не преувеличиваю. Потратить 12 часов на монтаж вместо 4-х часов тоже играет важную роль. Другой вопрос что это не основная затрата времени, как Вы написали ниже…
> На обдумывание, подготовку и запись старой серии про HTTP-фреймворк без монтажа у меня ушёл год. С монтажом ушло бы на неделю больше. Основное время занимает подготовка, структурирование, программирование и запись, а не монтаж.
Вот с этим уже сложно что-то мне подсказать. Тут Вы больше понимаете как можно оптимизировать. Есть темы которые так и не реализуются, а время на них потрачено. Это я тоже понимаю. Вся суть про монтаж у меня была сводится к двум факторам:
1. Мне показалось, что некоторые части можно оптимизировать (что вы уже и сделали), чтобы не тратить время на монтаж.
2. Плюс то, что вы хотели перезаписывать 50 скринкастов по причине только темпа, звука и картинки, что было указано Юлией в блоге данного поста, как одной из причин. Тут Вы сами больше знаете. Я тут поделился своим мнением. Можно спросить мнение большинства.
Но главное нужно понимать, что я нигде не писал о том, что не нужно вырезать вздохи ахи и так далее. Я говорил относительно картинки и звука.
> Плюс то, что вы хотели перезаписывать 50 скринкастов по причине только темпа, звука и картинки, что было указано Юлией в блоге данного поста, как одной из причин.
Перезаписать мы хотели только самые неудачные первые серии вроде HTTP-заголовков и геолокатора.
А все остальные эпизоды мы приняли решение просто более аккуратно переобработать (выровнять звук, исправить темп изменением пауз и дочистить мусор). Никто 50 эпизодов перезаписывать не собирается.
Дима дал несколько комментариев по своей работе, теперь я поясню по моим идеям.
> Переработка проекта ElisDN и demo-project-manager
> Это интересно, как старый Фреймворк немного взбодрить, но моё мнение — это не стоит целого обучения
> я бы не стал публиковать обучение по трансформации данного проекта
> большая часть займёт Upgrade со старой версии на новую
Как понимаю, вы имеете в виду про обновление кода этих проектов, поэтому и предлагаете написать всего по одной статье?
Я не занимаюсь программированием, и на эти темы рассказать ничего не смогу. Но до того, как проект попадает к программисту над ним происходит работа бизнес-аналитика, менеджеров, ux/ui дизайнера и т.д. Составляются требования, рисуются карты, по которым проходят посетители. Эта работа мне интересна, и её можно делать публично. Отсюда идеи по проектам:
ElisDN
Могу начать с аудита блога и создания семантического ядра, как писала в статье https://elisjuli.ru/project/semantics-elisdn. Под семантическим ядром подразумеваю не сбор ключей по вордстату. Это про ядро, за счёт чего блог может жить годы. И в любой момент, даже если автор сменит направление деятельности, блог продолжит существовать.
Могу показать работу с метрикой, тепловым картами, степенью дочитываемости контента и т.д. И так как на протяжении последних семи лет занималась контентными проектами, то затем рассмотреть темы про перелинковку, ссылки и т.д.
Project Manager
Если проанализировать полученный после запуска первого мастер-класса результат, то все спрограммированные функции нужны, но их мало. Поэтому можно их расширить и подключить интерактивный фронтенд, чтобы визуально можно было удобно работать с текущими делами.
При этом я недавно нашла интересное решение по ведению проектов, которым понравилось пользоваться Диме. И мне будет интересно рассказать, как я к этому решению пришла.
Deworker
Сейчас я готовлю презентации и отчеты для одного человека. Но то же разделение контента по авторам или создание рубрики вопросов-ответов, удобной системы меток — всем нужно заниматься либо внутри нашей команды и показывать публично только результат, либо показывать, как всё работает внутри. И это снова не про программирование.
Останавливает то, что вся моя работа воспринимается и будет восприниматься как единственно верное решение. Хотя при разработке она выглядит цикличной: сбор требований->анализ->уточнение требований->анализ->уточнение требований->анализ->уточнение требований-> и т.д.->простой и логичный результат.
Покажешь сразу результат, возникнет вопрос: а над чем там думать-то? Всё просто и понятно. Поэтому мне для работы больше подходит формат ведения блога нежели формат скринкастов.
> Отличие скринкастов от блога
> Моё мнение это одинаковые вещи
Блог — это дневник, в котором можно ошибаться, исправляться, показывать зрителям свой рост.
Скринкасты — это как пособие или методичка, можно с любого места начать читать или смотреть главу. Даже если они устаревают по материалу, к ним возвращаешься снова и снова за смыслами.
Поэтому к последним предъявляются повышенные требования.
> Вы сейчас выпускаете новости о проектах. А почему не опубликовать это на Deworker? Было бы полезно, а не только публиковать новости о новом скринкасте.
> Можно просто поделиться новостью, что вышла новая версия PHP, Symfony и что в нововведениях важного.
Deworker создавался для программистов. Новости проектов исходя из своих компетенций публиковать не смогу. Дайджест выпускает Дима на основе того, что в основном проделал он.
> на вашу площадку нужно привлекать других Авторов контента. Тогда это будет жить и развиваться даже без участия Дмитрия. Дмитрий может просто модерировать и отсеивать что не нужно.
> Оплата за просмотры, например) Как на хабре. Ведь это очень хорошая идея.
В теории всё так. Нужно дополнительно решить проблемы и вопросы:
— счётчика просмотров. Проблема пролистывания видео или откладывания просмотра “на потом”.
— накрутки просмотров. Для авторов это было бы выгодно.
— маркетинга и рекламы.
— количество времени на подготовку авторов, аппаратуру, которой нужно их обеспечить.
— в течение какого времени собирать просмотры контента
— узкой ниши программистов, которым это будет нужно.
И главное, в прошлом году я поставила эксперимент и записала 7 видео по разработке технического задания для аукциона, потратив 14 недель. Но за целый год каждое видео набрало всего по 50 просмотров. Вы бы какую сумму мне предложили?
> Как понимаю, вы имеете в виду про обновление кода этих проектов, поэтому и предлагаете написать всего по одной статье?
Да. Я говорю именно про код. Код Project Manager написан на Symfony 4.4. Сейчас уже Symfony 6.2. Плюсом устарела другая инфраструктура. И записывать на это всё видео будет очень долго. Кроме того пользы в этом может и не быть. Поэтому я предлагаю изменения записать не с помощью видео, а статьи. Возможно даже одной. Суть статьи будет заключаться в том, что «обновили Симфони, обновили дизайн, обновили другие зависимости» Кстати. Сейчас придумал важную мысль, прошу донести её до Дмитрия. Обновления кода ещё можно оформить с помощью комментариев. В комитах в описании писать важные части, а в названии комита писать изменения. А в блоге уже остаться на эти комментарии. Думаю, что будет выглядеть не плохо)
> Я не занимаюсь программированием, и на эти темы рассказать ничего не смогу. Но до того, как проект попадает к программисту над ним происходит работа бизнес-аналитика, менеджеров, ux/ui дизайнера и т.д. Составляются требования, рисуются карты, по которым проходят посетители. Эта работа мне интересна, и её можно делать публично. Отсюда идеи по проектам:
Эта тема в принципе не связана, как мне кажется, с каким-либо проектом. За пример можно взять Project Manager. Есть всегда вещи которые актуальны для всех проектов, а есть вещи, которые свойственны только для конкретного проекта. Я бы разделял это. И видел, что не только я это просил. Тогда появится возможность обновлять незвисимые скриктасты, а проектные скринкасты при этом не трогать. Тенденции дизайна меняется раз в 1-3 года, а управление задачами (Project Manager) меняется только от бизнес требований. Постановка задач может не отличаться от момента записи проекта, поэтому можно даже не обновлять Project Manager, а только обновить дизайн.
Project Manager
> Если проанализировать полученный после запуска первого мастер-класса результат, то все спрограммированные функции нужны, но их мало. Поэтому можно их расширить и подключить интерактивный фронтенд, чтобы визуально можно было удобно работать с текущими делами.
Всё верно. Не хватает масштаба иногда. Например, какие-то вещи типа уведомлений реализованы просто. В тоже время если их сделать хорошо — их можно переиспользовать. Более того у вас может получится в последствии не какой-то демонстрационный проект, а реальный продукт SAAS или Open Source. А это значит, что у вас появятся новые люди, которые будут владываться в это, в том числе и в плане видео. Вы, наверное, замечали что крупные компании всегда выступают с такими темами, как распил монолита на микросервисы и у них это возникает в реальном мире. У вас же не хватает этого реального мира, реальных пользователей, поэтому Open Souce какого-то проекта может реально помочь Вам) Вы решите много проблем, как мне кажется:
1. Вам не придётся придумывать темы и создавать ситуацию с проблемами старого легаси. Вы это всё получите от вашего Open Source) А так вам приходится каждый раз проект создавать, изучать домен и выдумывать что у вас будет)
2. Вы получите готовую кодовую базу и переиспользуемую инфраструктуру. В итоге те же уведомления вам придётся раз рассмотреть и внедрять.
3. Получится стандартизировать многие вещи.
4. Получите людей единомышленников и Авторов отвечающие за свои части. Кто-то будет записывать уведомления, кто-то будет рассказывать как мы поменяли дизайн в проекте и так далее..
5. Возможность заработка за счёт SAAS продукта, а так же за счёт других авторов, которым платится комиссия.
6. Возможность спонсорства Open Source проектов.
Например, я точно знаю, что аукцион был бы хорош для одной компании, которая занимается долгами. Всего таких площадок 4. Возможно слишком абициозно, но я смотрю глобально и далеко, есть к чему стремиться так сказать)
> При этом я недавно нашла интересное решение по ведению проектов, которым понравилось пользоваться Диме. И мне будет интересно рассказать, как я к этому решению пришла.
В целом это целится на отдельную статью в Deworker не знаю почему мы рассматриваем её в комментариях) Можно было получить больше обратной связи и ещё вовлечь аудиторию) И другие Ваши статьи я бы тоже публиковал в блоге на Deworker. Не все следят за Вашим блогом.
Deworker
> Сейчас я готовлю презентации и отчеты для одного человека. Но то же разделение контента по авторам или создание рубрики вопросов-ответов, удобной системы меток — всем нужно заниматься либо внутри нашей команды и показывать публично только результат, либо показывать, как всё работает внутри. И это снова не про программирование.
Отлично! Вы на верном пути, как мне кажется. У Вас есть проект Deworker и он объединяет несколько авторов. Разве это не есть хорошо?) И не страшно что это не про программирование. Тут главное понять границы ваших трудов. У Вас же это возникло — почему этим не поделиться. Возможно это тоже будет кому-то полезно. Ведь Бизнес аналитика это тоже не про программирование. Мне кажется наша жизнь давно изменилось и в конечном счёте любой проект в будущем будет IT проект. То есть IT проект уже давно не заканчивается кодом. Мы уже в другой реальности и это уже часть нас. Возьмите обучение. Раньше обучались все в аудитория, а теперь на сайте Deworker. Так что я бы не ограничивал себя только на коде. Иначе это очень узко) Хабр считается что это для IT специалистов ресурс, однако мы видим всё больше статей разных областей. Тут важно найти метрику, по которой будет оцениваться результат.
> Останавливает то, что вся моя работа воспринимается и будет восприниматься как единственно верное решение. Хотя при разработке она выглядит цикличной: сбор требований->анализ->уточнение требований->анализ->уточнение требований->анализ->уточнение требований-> и т.д.->простой и логичный результат.
Ну и пусть. Работа Дмитрия же не расценивается так. Хотя я в некоторых подходах в своих проектах делаю не так как Дмитрий учит на уроках. Например, у меня есть для докера php-base образ который имеет все базовые вещи. Это позволяет ускорять сборку, так как при изменениях базовый образ берётся из кэша. Но это не значит, что у Дмитрия только единственное верное решение. Для этого вводится Авторство. Это мнение автора, а не всего проекта. Более того у Вас может быть какой-то пост, который будет очень компрометирующим и это нормально) Я помню как Дмитрия хейтили за пример работы Докера или какой-то команды. Так что не надо бояться. Промахнуться можно везде, но это не значит что не надо вносить что-то новое. Вы же из-за ошибок в проекте не прекращаете внедрения новых фич в проект. Будет неудачно — скроете)
>Покажешь сразу результат, возникнет вопрос: а над чем там думать-то? Всё просто и понятно. Поэтому мне для работы больше подходит формат ведения блога нежели формат скринкастов.
Ведите блог на Deworker. Никаких проблем)
> Блог — это дневник, в котором можно ошибаться, исправляться, показывать зрителям свой рост.
> Скринкасты — это как пособие или методичка, можно с любого места начать читать или смотреть главу. Даже если они устаревают по материалу, к ним возвращаешься снова и снова за смыслами.
Не вижу разницы) Я помню Дмитрия, когда он вёл 6-ти часовые стримы и потом он перешёл в скринкасты. Причём он сам называл эту проблему и почему он теперь перешёл на формат скринкастов. Я помню как Дмитрий не правильно объяснил работу докера в Скринкасте Slim из-за чего он переписал его. Вы сами сейчас переписываете скринкасты по причине ошибок по звуку, темпу и шуму… Кроме того я читаю статьи из блога Дмитрия, которые были написаны ещё в 2016 году. Это тоже методичка для меня. Так что отличает эти форматы только подачу материала!)
Скринкаст — это донесение материала (кода, схемы, др) через запись видео с экрана.
Блог — это донесение материала (кода, схемы, др) помощью текста.
Вот и Всё отличие!)
> Поэтому к последним предъявляются повышенные требования.
Мне кажется, Дмитрий и к блогу тоже повышенные требования предъявляет)
> Deworker создавался для программистов. Новости проектов исходя из своих компетенций публиковать не смогу. Дайджест выпускает Дима на основе того, что в основном проделал он.
Программисты тоже не заканчивают свою деятельность на коде. Я видел, что Дмитрий выложил Видео с игрой на гитаре. Так же у Вас это само приходит…
> В теории всё так. Нужно дополнительно решить проблемы и вопросы
Это да. К этому нужно постепенно двигаться. Однако это может быть постепенно и на начальном этапе могут быть люди, которые могут поделиться без монетизации. Я думаю, что у Вас есть в подписках идейные люди, которые хотели бы донести что-то своё безвозмездно. А потом уже включить манетизацию.
> И главное, в прошлом году я поставила эксперимент и записала 7 видео по разработке технического задания для аукциона, потратив 14 недель. Но за целый год каждое видео набрало всего по 50 просмотров. Вы бы какую сумму мне предложили?
В этом и суть поощрения авторства. Авторов поощряют за хорошие успехи. То что «выстрелит» никто не знает. Сейчас это может быть 50 просмотров, а в какой-то момент 1 млн. Много факторов. Но если Вы знакомы с YouTube, то вы понимаете о чём я говорю. Есть каналы, которые имеют 1000 подписчиков и у них на одном видео 1млн просмотр) Так что это вопрос популярности темы, её подачи и так далее)
Кроме того можно вначале наполнять материалами сайт, набирать аудиторию. Как я сказал выше вначале авторы могут делиться своими наработками бесплатно. Монетизация придёт потом. Или определить, что за 1000 просмотров будет оплата 50 рублей. Это как пример. Если ролик набрал 50 просмотров — оплаты нет)
> Суть статьи будет заключаться в том, что «обновили Симфони, обновили дизайн, обновили другие зависимости» Сейчас придумал важную мысль, прошу донести её до Дмитрия. Обновления кода ещё можно оформить с помощью комментариев. В комитах в описании писать важные части, а в названии комита писать изменения. А в блоге уже остаться на эти комментарии. Думаю, что будет выглядеть не плохо)
Это не про то, что просто взять код старого проекта и добавить несколько коммитов по обновлению его до свежей версии Symfony. Это новый мастер-класс по разработке проекта на Symfony + Angular на свежих технологиях и бандлах.
> Вы сами сейчас переписываете скринкасты по причине ошибок по звуку, темпу и шуму…
Не переписываем, а переобрабатываем.
> Я помню как Дмитрий не правильно объяснил работу докера в Скринкасте Slim из-за чего он переписал его.
Скринкаст по Docker я не перезаписывал. Не занимайтесь клеветой.
К сожалению, я не слежу за тем, что вы перезаписываете. Тем более это невозможно отследить на Deworker. Но на стриме вы об этом говорили. Таймкод: 1.06.20 https://youtu.be/DyvMHgPJG-w Кроме того вы говорили об этом где-то ещё. Либо в чатах, либо в других видео. Быстро не вспомню где это было. Но если это не так, то извиняюсь.
Не знаю почему, но все Абзацы поехали)) Хотя и ставил Enter. По поводу комментария — он получился объёмным) Возможно его и не стоит даже публиковать. Решите сами. Я хотел донести это Вам. Цели публикации нет) С Днём Рождения!)
Спасибо за поздравления)) да, ваш комментарий получился объёмным, зато есть над чем поразмышлять.
Хейт — когда комментарий не аргументирован и написан с целью оскорбить человека. Здесь же все всё написано по существу и отражает вашу точку зрения. Ничего обидного или оскорбительного в этом я не увидела.
Тогда я рад, что смог Вам помочь своими мыслями
Здравствуйте Юлия!
> похоже, что от моей молчаливой работы я скоро могу утратить навык устной речи
Тут напрашивается ёрничество — типа, не надо огорчаться — традиционно молчаливость жен цениться крайне высоко 🙂
По первых строках: Ваш с Дмитрием проект — уникален. Других таких не знаю.
Если его не станет — для меня это будет личная трагедия.
Всё ниже — индивидуально IMHO.
>Первая — не хочется ради этой информации открывать свой собственный канал, так как видео относятся >именно к нашим общим с Димой проектам. А если записывать на Деворкер, то у проекта получится >тематика “программирование и не программирование”, то есть размывается основной контент.
Читать в одном месте мне удобнее чем в трех. Конечно, при должном структурировании: рубрики, разделы ..
>Вторая — а кому это надо и будет ли полезно? И вообще, разве интересно смотреть, как устроена работа у >других?
да, интересно
>В скринкастах предполагается длительное взаимодействие зрителей с материалом. Поэтому скринкасты >должны быть выше по качеству и всегда актуальны.
>К хорошим видео зрителям захочется возвращаться снова и снова.
да, именно
>Бонусом идёт расстановка отсутствующих тайм-кодов.
Каким таким бонусом!?
Щас поясню 🙂
Особенность ценных материалов Дмитрия в том, что его материал профессиональный и сложен для восприятия среднему человеку, который об этом слышит впервые. Да, часто и программисты на зарплате годами не используют новые для них технологии.
Поэтому неизбежно возвращение и пересмотры.
Поэтому важна качественная подача и с педагогической точки зрения и в части баланса сжатости/развернутости/ качества звука_картинки.
Чтобы обучаемый мог сконцентрироваться на новых для него понятиях. Чтобы он был уже подготовлен к новым вещам и/или снабжен ссылками на вспомогательный материал.
А раз неизбежны пере просмотры и повторный многократный поиск материала , то тайм-коды и оглавления для каждого эпизода просто обязательны. Молодцы, что сделали.
Также ОЧЕНЬ полезны будут теги по технологиям в рамках всего сайта, которые будут вести как на эпизоды статьи, так и на конкретный тайм-код эпизода.
Пример тегов: ORM, Сериализация, Валидация, MiddleWare ..
Текущее качество материалов:
Сейчас сжатость информации в видео сейчас кажутся оптимальными. Если нужно — можно замедлить проигрывание.
Воды в видео нет совсем — и это ОЧЕНЬ радует.
Оптимальная продолжительность видео для меня — пол часа. И никак не больше часа — я лично теряюсь в таком объеме новой информации + трудно искать в будущем.
Да, переработанные видео воспринимаются полегче, но не радикально.
Однако, такой здоровый перфекционизм мне лично кажется здесь уместным.
Ведь и древние, шестилетней давности, статьи и /видео Дмитрия не потеряли актуальности, потому что Дмитрий подходил серьезно и не писал быстро , «на отвали»
Время выхода статьи/видео указывать таки надо. Без них — неудобно.
Хорошо бы у видео была история или (что проще) дата перезалития последей версии.
Так как пересмотр неизбежен (см выше) и видео становиться твоим другом, то хотелось бы знать какие видео исправлены.
>Замечаете разницу в подаче материала, звуке, обработке?
да
>А вы часто пересматриваете наши эпизоды?
К сожалению недостаточно часто. И это тормозит мой проф рост.
Понимаю, что проще найти время на пересмотр видео/ заставить себя пересмотреть. И это избавит от многих самостоятельных экспериментов в коде и от прочтения тонн информационного мусора, чтобы отыскать зерно в соломе.
Но пересматриваю нечасто, так как просмотр «всего» от начала до конца — не позволяет текущая занятость рабочим проектом. И психологически трудно настроиться на пересмотр ВСЕГО зная, что найти нужную информацию будет трудно.
Зато пытаюсь искать актуальные эпизоды внутри разных видео, чтобы закрыть самый горячий, для текущей потребности, пробел в знаниях. Но этому препятствует пока еще несовершенная навигация, хоть и сильно улучшенная с появлением тайм- кодов.
Сейчас на работе переписываю старый легаси проект в соответствии с тем, что узнаю от Дмитрия.
Текущая тактика моего обучения такова:
Пробегаю быстро новый эпизод. Половину не понимаю, так как многие вещи новые СОВСЕМ и требуют напряжения мозга.
Затем возвращаюсь и пересматриваю, когда пишу код по этой теме.
По этой причине, хотелось бы конечно невозможного: 🙂
— быстро выходящие эпизоды с тем, чтобы не ждать два года материала про базовые технолгии, например, Symfony Forms и «Role Based Access Control » — с тем чтобы просто знать, что такая технология есть и когда ее можно применять.
— Качественных эпизодов с хорошей навигацией для пере-просмотров при последующем тщательном изучении.
>Какие есть ожидания от развития нашего основного проекта?
Так держать! Не снижайте планку. Не превращайтесь в СМИ, которых много.
Концентрируйтесь на востребованных вещах: материал для профи + средства подачи, чтобы максимизировать его усвояемость.
Кстати, очень помогли понимать основную серию (аукцион) вспомогательные серии типа
— Взаимодействие объектов
— Использование HTTP заголовков
..
— Раздельчик «библиотека программиста» будет актуален. С рекомендованными Дмитрием книгами и с его аннотацией: о чем она и зачем, особенности книги.
Еще иногда не хватает большей гибкости в комментировании, как здесь. так и на deworker: удаление своих комментов. Возможность их редактирования долгое время. Это также поможет держать комменты в чистоте от спама первых впечатлений и непродуманных мыслей.
Желаю всяческих успехов и благодарю за важный труд!
> По этой причине, хотелось бы конечно невозможного: ?
— быстро выходящие эпизоды с тем, чтобы не ждать два года материала про базовые технолгии, например, Symfony Forms и «Role Based Access Control » — с тем чтобы просто знать, что такая технология есть и когда ее можно применять.
— Качественных эпизодов с хорошей навигацией для пере-просмотров при последующем тщательном изучении.
> — быстро выходящие эпизоды с тем, чтобы не ждать два года материала про базовые технолгии, например, Symfony Forms и «Role Based Access Control » — с тем чтобы просто знать, что такая технология есть и когда ее можно применять.
А вы это до сих пор не знаете?) Формы Symfony в текущих реалиях, когда есть отдельно api backend и frontend js не нужны. Так что Можете не тратить время на изучение) А RBAC Дмитрий давал ещё на Yii2. Могу даже скинуть статью тех годов с Хабра, правда не от Дмитрия)) https://habr.com/ru/company/custis/blog/248649/?ysclid=l7o6ao26ih371563058 Там же прочитайте про ABAC
Максим,
Благодарю за статью!
>А вы это до сих пор не знаете?) Формы Symfony в текущих реалиях,..
Да, я этого не знаю. Фишка в том, что я уже перерос курсы для начального обучения. Но профи еще не стал. Поэтому миссис и мистер Елисеевы — моё спасение.
Да, у меня есть свой боевой PHP проект. Я бывший админ. И если бы работал не в одиночку, а в dev компании, где бы надо мной шефствовали старшие разработчики, то наверное я был бы в курсе реалий.
> Формы Symfony в текущих реалиях, когда есть отдельно api backend и frontend js не нужны
Это крайне интересная информация.
Правда, сразу ей руководствоваться мне мешают две вещи:
— во фронтеде я еще слабее чем в PHP
— мой легаси проект настолько страшен, что до реакта еще там далеко.
> Да, я этого не знаю. Фишка в том, что я уже перерос курсы для начального обучения. Но профи еще не стал. Поэтому миссис и мистер Елисеевы — моё спасение.
Странно) Звучит как нежелание учится или нежелание воспринимать информацию из других источников. О формах Симони можно узнать даже из документации.
> Да, у меня есть свой боевой PHP проект. Я бывший админ. И если бы работал не в одиночку, а в dev компании, где бы надо мной шефствовали старшие разработчики, то наверное я был бы в курсе реалий.
У меня тоже есть и я не работаю ни в какой компании. Однако это не значит, что я не могу что-то изучить самостоятельно.
> во фронтеде я еще слабее чем в PHP
Умейте быстро меняться. Я тоже не знал фронт. Сидел и изучал.
> мой легаси проект настолько страшен, что до реакта еще там далеко.
Это никак не мешает. Вам главное сделать api. API будет вашим контрактом между приложениями. А уже внутри меняйте что хотите и как хотите. Можно даже делать трансляторы из API в свой легаси в случае если сущности разносятся на разные модули или разные сущности. Ваш API как Gateway.
>Формы Symfony в текущих реалиях, когда есть отдельно api backend и frontend js не нужны
Максим, вы разбудили во мне вулкан любопытства. Рискну поофтопить:
А разве Симфони формс нужны не для упрощения отрисовка/валидация/сериализация/запись в одном флаконе?
Разве фронтенд это может как то заменить?
Имеется в виду, что формы удобны для классических проектов с отрисовкой в Twig с встроенным JS. Если у нас только API без отрисовки, то формы уже не так полезны. Сериализовать и валидировать там можно напрямую сериалайзером и валидатором без форм.
Дмитрий ответил на вопрос о чём я имел ввиду