Влад Токарев

ИМХО Vue
Во-первых, он самый свежий и в нем учтены косяки многих других фреймворков
Во-вторых, он самый производительный, шустрее можно сделать только на нативке, и то не всегда
В-третьих, он довольно прост в освоении, у него самая адекватная документация с адекватными переводами на множество языков, включая русский
В-четвертых, если уже знаете React, то быстро (лично мне хватило пары часов) въедете в основные принципы, так как в основе похожая система компонентов

если же проверять размер окна, современные смартфоны
выдают большие цифры (в районе 1000 пикселей).

Смотрите не размер экрана, а размер вьюпорта
viewportsizes.com
screensiz.es/phone

пусть /dev/sda1 это ваш старый диск и раздел
а /dev/sdb1 - новый, отформатированный раздел, куда вы хотите перенести /home

mkdir /mnt/newhome && mount /dev/sdb1 /mnt/newhome
rsync -a /home /mnt/newhome

Проверяете все ли нормально перенеслось.

редактируете /etc/fstab
там ищете старый хоум, или если его нет вписываете что-то вроде

/dev/sdb1 /home           ext4   defaults        0       1

Нужно чтоб адреса и тип ФС были правильными.
После чего
mount -a

Главное правило счастливого энтерпрайза - не тащить методики и технологии в которых нет опыта. Если вы не работали на проектах с DDD, не делали своих пет проектов чтобы опробовать подход, то не надо тренироваться на больших проектах.
Я уже 10 проектов в мире симфони видел и с тремя работал, везде попытки сделать DDD заканчивались невероятной сложностью поддержки после которой даже битрикс не кажется ужасом. 4 дня и изменения в 32 файлах чтобы добавить в список сортировку и фильтрацию... Наверное, можно писать на DDD правильно и с быстрой разработкой и лёгкой поддержкой, но я ещё таких проектов ни сам не создавал, не работал с чужими, не видел в качестве примеров. Поддерживать 10 летний легаси стартанутый на php4 с глобальными переменными гораздо проще чем любую поделку ddd-шников.

Из личного опыта, вкратце:
1. Не используйте фасады, только dependency injection, благо автоматическое разрешение зависимостей в Laravel очень мощное и удобное.
2. Не используйте Eloquent, используйте Doctrine. *
3. Не стесняйтесь использовать асинхронные задачи. При желании можно с их помощью реализовать полноценный CQRS.

* - Если, конечно, в вашем представлении сущность бизнес-логики соответствует модели ORM, ведь DDD предполагает разделение "domain layer" от "persistence layer", хотя Doctrine ползволяет довольно безболезненно их смешивать. В любом случае, Eloquent - худшая часть Laravel, и, наверное, одна из самых неудачных реализаций ActiveRecord на PHP.

https://siipo.la/blog/how-to-use-eloquent-orm-migr...

Можете добавить default null поле для нового хеша пароля.
На момент успешной авторизации вы знаете действительный пароль пользователя, значит если новый пароль в базе null, а старый хэш совпал, то сохраняете новый хеш в новое поле, а поле со старым паролем скидываете в null.
Через пару месяцев/полгода/год/выбрать_по_настроению вырезаете код старого хэша и дропаете колонку из базы. Всем желающим авторизоваться, но у кого стоит null вместо пароля - пишете, что необходимо пройти процедуру восстановления пароля.

Активная аудитория изменение не заметит. Теми, кто заходит слишком редко - придётся пожертвовать и заставить пройти более длинную процедуру.

Нет, не стоит, подождите 2 года пока Fuchsia допишут, потом еще 2 года пока появятся первые устройства, потом еще 5 лет пока откажутся от обратной совместимости с приложениями Android, вот тогда и начинайте изучать мобильное программирование!

Ответ один: Только NDA.
Всё остальное - полный бред:
После увольнения - трудовой договор прекращает своё действие.
Принуждение оформления любых других бумаг или шантаж/угрозы преследуются по закону.

smstools3

Hostinger не надежный бесплатный тариф, постоянно тормозит и проблемы всякие постоянно. Лучше возьми нормальный платный хостинг, тем более что тестовый период на многих есть. Что за проект если не секрет?

50% - абстрактная цифра. Необходимо показать менеджеру работу. Но не код. Т.е. на доступном серваке разворачиваете код, кидаете ссылку, сверяете по пулу задач/ТЗ, какие пункты сделаны. Если полноценно ни одного - какие требования оплаты вообще могут быть? Если там реально наберётся процентов 40 сделанных тасков, то можно обсудить условия оплаты и предоставления кода. Но с такими прокатами я бы лично не стал работать дальше в этом проекте. Если только ребята согласятся поднять оплату и заплатить сразу 50% от новой суммы, а не аванс от старой. И дело не в том, что это хорошо или плохо. Просто разработчик и заказчик берут на себя обоюдные обязательства. Искать нового программиста для доделки 60% проекта - это гарантированное увеличение бюджета и трата времени. Если люди реально готовы платить, а не обманывать, они вам предложат такое увеличение при условии адекватной демонстрации с вашей стороны.

Резюмирую:

1. Поднимаете проект на своей стороне.
2. Проводите демонстрацию.
3. Отмечаете закрытые пункты заказа.
4. Ставите заказчика перед фактом: "исходник он получает при условии оплаты обещанного аванса, но при таком отношении, после передачи кода вы уходите из проекта". Основание: вы не получили пока ни копейки. Договора нет. Со стороны заказчика устное соглашение не соблюдалось и нет гарантий, что будет соблюдаться. Если заказчик настаивает на исполнении обязанностей, говорите, что отдадите код после подписания договора. Юридически, если нет договора, факт оплаты подтверждает сделку. Т.е. договор или оплата. Предпочтительно - оплата.
5. Если сошлись на оплате, и заказчик просит пересмотреть ваш уход из проекта, отказываетесь до тех пор, пока заказчик не поднимет ценник. Сами ищите другой проект. Не факт, что заказчик пойдёт на уступки. Если второго проекта не будет, а заказчик согласится поднять цену, пусть доплатит сразу так, чтобы в сумме вышло 50% от общей суммы. Завершаем проект, радуемся.

Примерно в то время когда вы покупали, какраз была смена модели лицензирования:

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

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

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

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

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

P.S. Данный ответ достаточен и подробен. Если вам нужно понимать глубже - учите программирование, тогда вы сможете задать более правильные вопросы.