German Jet

Можно реализовать примерно так
1) создать для задачи колонку isRead(0/1 не прочитано/прочитано)
2) при создании записи добавлять в кеш с привязкой к пользователю, что у него есть непрочитанная задача

Yii::$app->cache->set('newTask-user-'. $userId, 1);

конечно нужно сначала проверять счетчик на существование и инкриментировать его. Например, это умеет редис
https://yiigist.com/package/drsdre/yii2-redis-coun...
В общем, если счетчика нет, то он создается, если есть, то берется его старое значение и делается +1
3) Когда пользователь зашел в список задач, то идет обращение не в БД, а к этому счетчику и пользователь видит (+1, +2 и т.д).
Когда заходит в конкретную задачу, то если колонка isRead = 0, то записываем 1, а счетчик делаем -1.
4) Наверное, еще придется предусмотреть "разогрев кеша", если он упал(на случай если вы предполагаете, что нагрузка будет реально большая)
Для этого пишем задачу, которая запускается при запуске сервера кеширования, в которой берем count всех непрочитанных задач, сгруппированных по пользователям и записываем эти значения в счетчики.

Ну так у Вас практически все уже сделано!

Осталось самое мелкое и незначительное:

1. Купить у вашего интернет провайдера статический IP-адрес
   
2. Купить красивое доменное имя
   
3. На ns-сервере (его продавцы доменных имен предоставляют бесплатно) привязать ваш домен к вашему IP с помощью A-записи
   
4. Настроить Apache на ответ по запросу этого доменного имени
   
5. Купить для домена сертификат или воспользоваться бесплатным от Let’s Encrypt (можно и без него, но хром и мозила обещают все сайты без HTTPS показывать как неблагонадежные - если такое устраивает, то пропускайте этот и следующий пункт)
   
6. Установить купленный сертификат в вашей системе и настроить Apache на его использование
   
7. Добавить в ваш фаервол разрешающие правила для вашего HTTP/HTTPS трафика
   
8. Если вы работаете из локальной сети, то еще возможно нужно будет настроить форвардинг HTTP/HTTPS трафика с вашего роутера на компьютер с физически установленным Apache (где при этом база 1С находится не имеет значения; главное, что бы на компе с веб-сервером стояли 1С-кие библиотеки и был прямой доступ по локалке)
   

По вебу вообще сложно что-либо предугадывать даже на 5 лет вперед, не говоря уже о 20-30. Какими они будут эти web 4.0, 5.0...n.0 - вряд ли достоверно известно даже в Google и Microsoft.

Наиболее вероятное развитие - всё будет браузером. Операционная система - подобие браузера, и всё в облаках - софт в виде web-сервисов (подключаемых из аппстора на рабочем столе), данные в виртуальных хранилищах и т.д. Даже игры будут крутиться на серверах, а пользователю будет передаваться только "клиентская часть" в видеопотоке. При этом всё будет кроссплатформенным с минимальными требованиями к конфигурации устройства. Не важно, ПК у пользователя (обычный или квантовый), ноутбук, планшет, смартфон, шлем VR, телевизор и проч. - каждый будет иметь возможность оплатить доступ к какой-нибудь GTA 10 и зарубиться в неё на максималках.

Соответственно, привычные в 2000-х годах сайты на PHP также поменяют вид и преобразуются в SPA-приложения, подгружаемые на рабочий стол пользователя по клику в сторе.

Дело в том, что такая модель полностью убивает пиратство и дико выгодна коммерчески всей IT-индустрии, потому и считается наиболее вероятной. Уже прут первые потуги типа Chrome OS, перемены начнутся, когда выкатится браузерный Windows и ТОП-500 web-сервисов адаптируются под него, а затем и под версии от Google и Apple. Собственно, примерно то же произошло с мобильным рынком с появлением Android.

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

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

Продолжение:

Пришел python\django juniorом с улицы. За немалое время работы сожрал пуд соли. Самое большое разочарование - все ищут питонистов для быстрой разработки (порог вхождения ниже наверное только у php) и берут джунов на не джуниорские задачи. Я за первый месяц работы что только не писал, от системы скидок для интернет магазинов на Django, до админки системы курьерской доставки интернет-ритейлера написаной на связке Flusk+Vue+Jquery которую до меня писал десяток человек и все бросали.

Никто практически никогда не готов тебя учить, если на более "мейнстримных" языках ты получаешь более низкий оклад, но больший штат серьезных девов с многолетним опытом и высокий шанс того что за тобой будут "присматривать", то попадая в компанию которая пишет на python - ты сам по себе. Потому что питонистов тупо мало и стоят они дорого, никто не хочет тратить их время на всякие кодревью и митапы.

Не согласен с оратором выше, джун это просто человек способный писать работающий код. Как он это делает и что этот код из себя представляет - вопрос второй. Я пишу нереальные костыли и ничего, заказчик доволен, начальнику пофигу, зп на карточке.

Самый простой вариант - создать свой класс, наследованный от Html и использовать его во всем проекте:

<?php
namespace app\helpers;
class Html extends \yii\helpers\Html
{
    public static function phone($phone, $options = [])
    {
        $options['href'] = 'tel:'.$phone;
        if (!isset($options['class'])) {
            $options['class'] = '';
        }
        return static::tag('a', $phone, $options);
    }
}

А дальше несколько вариантов:

• Добавить еще несколько удобных методов и оформить все это в виде пакета composer, пример.
  
• Сделать pull-request в yii2 или тому же Картику.
  

А теперь от теории к практике, я сам несколько раз попадал под проверки, а также несколько лет "работал" независимым специалистом по киберпреступлениям, в том числе на проверках лицензионной чистоты. Руководство всегда показывает пальцем на админа и говорит "Мы не знали, вот ответственный специалист!" Заканчивается это тем, что компанию штрафуют, а админу прилетает срок. Наличие бумажки о том, что директор знал об установке пиратского софта трактуется судом как преступный сговор. Позиция админа "я не обязан разбираться в тонкостях лицензирования" - это как позиция бухгалтера "я не обязан разбираться в тонкостях налогообложения". Правильных решений может быть только два - либо заставить компанию перейти на лицензионное ПО, либо уволиться.

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

1. Ни в коем случае не писать никаких бумажек, как советует pfg21 .
2. Ни в коем случае не говорить открыто, что это-пиратка.
3. Ни в коем случае не вести "журналов установки пиратского софта".

Зачем: В случае чего все дружно-дружно покажут на Вас. Ответственность несёт Директор. Скорее всего - даст взятку. Но если и он решит Вас слить - самый плохой вариант (остальные-то работники наверняка подтвердят). И эти бумажки будут показывать процесс подготовки к преступлению, факт его завершённости. А умысел как-нибудь найдётся. Плюс эта бумажка - подтверждение сговора (т.е. уже ч.2)

Как делать: Вы не обязаны разбираться в тонкостях лицензирования. Кто угодно пусть пишет что угодно в стиле тыжпрограммист, но если такого навыка/обязанности нет в должностной инструкции (наверняка нет, и надо, чтобы не было), если не было такого курса в ВУЗе или Федерального Закона (тут условно) - не обязаны. Вы просто ставите то, что просят. Так, как просят. С дисков, которые Вам предоставил согласно ТК Работодатель (в качестве инструмента).

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

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

Поначалу основной упор пришлось таки сделать на DevOps, все работало на GitLab, GitLab CI, Docker и хостинге Flops.ru. Это очень муторная, долгая работа по первичной настройке всего и вся. Не уверен, что её получится избежать.

Разработка проекта велась следующим образом:
1) Есть репозиторий с "заготовкой", копируется в новый репозиторий.
2) Подключается GitLab CI, в переменных среды задается вся-вся конфигурация. Например, на каких серверах запускать, на каких доменах и так далее.
3) Программисты выпинываются на прогулку по другим репозиториям в поисках удачных технических решений в похожих проектах.
4) Пушат код, он заливается на сервачки. Каждая ветка - на свой поддомен, фичи тестятся отдельно. Кодревью, Юниттесты, Мерж реквесты - это все реально помогает.

В итоге когда все завелось и начало помогать, а не делать больно (примерно через пол года), появилась другая проблема - как нам то же самое соорудить на фронтенде? А это уже совсем другая история...

посмотрите [Knp University] Learn Symfony 3 и будет вам счастье.
Бест практики описаны, как ориентир можно рефакторинг Фаулера держать под рукой и как ни странно практика, много практики, придерживаясь основных идей: логика в сервисах, работа с базой в репозиториях, сущности простые и прозрачные, контроллеры держим тонкими. Внимательно изучите возможности аннотаций, di, security voter`s, расширения твига, ассеты и прочие ништяки симфони, чтобы возможности для реализации правильной архитектуры были максимальными. Если кажется, что с задачей уже не раз сталкивались коллеги ранее, посмотрите готовые бандлы, чтобы не тратить время на велосипеды (за исключением ситуаций прокачки скилла написания оных) Тут главное соблюдать границу между техническим перфекционизмом и реальностью :)
Как уже упоминали демо приложение - вполне достойно изучения, а вот насчет Sylius'a неоднозначное впечатление, довольно давно его просматривал, symfony way как-то не проглядывается, хотя вполне занятно и интересно сделано.

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

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

Я был на вашем месте лет 5-6 назад. Точно так же достиг в Java определенного уровня, после которого все стало как-то не интересно. Новые задачи перестали быть новыми. Творческий процесс программирования стал машинальным кодингом. Думаю, подобный процесс выгорания характерен для любой профессии, не только для программирования. Психолого говорят, что профессионализм достигается примерно за 5 лет. Дальше рекомендуется менять работу.

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

Можно еще в погоне за новыми проектами поискать работу на Upwork/Freelancer. Но Java-разработчикам там тяжело. Либо будет мелочь на подобие студенческих курсовых, либо будет нужен удаленный разработчик на фуллтайм в большой проект. Именно то, что вы сейчас делаете.

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

Сейчас и этот пятилетний цикл подходит к концу. Пилю стартап :-).

Как правильно посоветовал Дмитрий, нужно найти то, что нравится и идти в эту сторону. Должно быть "движение к" вместо текущего "движения от". Критерий выбора: "настоящая работа такой и должна быть – чтобы вы готовы были за нее доплачивать, лишь бы вам разрешили ее делать." - НЛПшники.

Удачи!

Как вы это делаете?! За 17 лет работы в ИТ у меня ни разу не возникало вопроса "Куда двигаться?", только "Где взять времени на освоение всего этого бесконечного изобилия технологий, углублённого изучения уже знакомого и реализацию множества идей?"

пришло понимание, что программирование это не знание языка и фреймворков

Какой вы для себя ответ определили на вопрос что же такое программирование?

От этого ответа и зависит вектор будущего движения. Я например понимаю что есть ещё пару языков которые я бы хотел освоить, но дальше другие языки учить нет смысла и меня интересует либо вектор развития в виде узкоспециализированных алгоритмов под конкретную задачу, либо изучение баз данных, благо в этом направлении сейчас есть где развернуться.

Стартап? Определите какая потребность не закрыта у вас и друзей и пилите его каждый вечер по часу-два.

Big Data это ведь не самоцель. Вот прошли вы курс допустим. Что вы будете бигдейтить, на каких данных?

Самое главное ответьте себе на вопрос что вам по-настоящему нравится и двигайтесь в эту сторону.

Ну возьмите Heroku.
Там все тоже - только завернуто гораздо удобнее. Минимум телодвижений по администрированию.
А Docker, Ansible, Vagrant - это вы еще увязните в изучении...

Если у вас количество серверов за десяток не выйдет и нет надобности быстро разворачивать новые чуть ли не ежедневно, вам не нужны Doker, Vagrant, Ansible. Вы — не Google.