hubramubr

Не пишешь тесты - ты плохой программист?
Это от задачи зависит. Автоматизированное тестирование - это вещь. Но на недорогих проектах обходятся без этого.

Есть тесты серверной части, есть тесты JS, есть тесты функциональные, есть юнит-тестирование. Они все пишутся по разному и на разном.

Ну, например, Selenium используется для тестов с эмуляцией пользователя.
А методика юнит-тестирование как правило описана в документации к используемым инструментам.

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

Самый простейший вариант - разделять время. Днем один пользуется аккаунтом, ночью другой.

Считай 2 Г на пользователя под RDP чтобы там ПО нормально шевелилось. 2 Г на AD, 2 Г на почтовый и пр. - все задачи по 2 Г.

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

И еще ты забыл про очень важную и дорогую вещь RAID - я бы положился на RAID 1+0 с не менее чем 10 рабочими дисками + 2 HOT. На таком количестве дисков уже не важно SSD или HDD. Причем RAID с батарейкой, чтобы можно было кэш по записи включить. А это дорого все.

После того как общую сумму увидишь - у тебя не будет проблем выбирать гигагерцы. Выбирешь сколько денег дадут на них....

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

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

На клиенте сжатие еще более затратно. Батарейка будет жраться - мама не горюй. Плюс неприятное ожидание и тормоза у пользователя

С другой стороны - каналы связи. Если ваше приложение только на Wi-Fi, то можете и не сжимать на клиенте.

Короче, дилемма.

Что касается серверного сжатия - то оно нисколько не затратно. Есть специализированные сервисы (не Youtube, а сырые, для создания своих видеосервисов), которые за небольшую денежку на своем специальном железе будет и сжимать и хранить и отдавать видео в нескольких разрешениях и форматах.

Написать серверную часть самому - очень затратно.

Win ничего не плодит. Можно при инсталляции указать, что разделы бэкапа и пр. не нужны.
Lin плодит даже больше - по уму нужен отдельный swap, root, home, usr, efi.

Если вы используете uefi то как минимум мелкие разделы под это дело вам все равно нужны. Для всех ОС. В MacOSX, в совершенно другой оси, тоже так.

Разрешение это круто.
Но сервис загнется.
Вполне достаточно оферты.

Пока вы демонстрируете конечному пользователю небольшой огрызок контента (как это делают поисковые системы), а затем предлагаете перейти на конечный сайт - все законно.
Иначе - попадос на авторское право.

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

Вы еще на этапе хранения задумались....
А каково будет по множественным фильтрам делать отбор?
А с тем, чтобы показывать покупателю, а сколько товаров после применения одного или двух фильтров? И с отключением после этого ненужных (невозможных) фильтров?
Зачем вы вообще это делаете на sql?
https://habrahabr.ru/post/261137/
или
https://habrahabr.ru/post/186572/
или
https://habrahabr.ru/post/132118/

Первое (ссылки) более законнее.

1. Тех. поддержка за денежку. Кроме них вряд ли кто лучше знает свой фреймворк. Да и рекламируется прежде всего автор фреймворка.
2. Внимание потенциальных работодателей, предложение работы за большие деньги. Это насколько распространено, что уже прямым тестом пишут в документации на фреймворки - я бедный студент из бедной страны, заберите меня кто-нибудь отсюда. Я лично видел.
3. Выход на поддержку сообщества. При том, что фреймворк развивается так как нужно автору. Фактически же только автор принимает решения какие merge request принимать, а какие нет. То есть получение бесплатных рабочих рук. Для того же пункта 1.

Никуда.
Эти специалисты не нужны в таком числе, а уж тем более в том качестве на котором их готовят.

Программисту высшее образование полезно. Но не нужно.
Имеет значение для более легкого получения рабочих виз в Европу, имеет значение при работе на гос. предприятиях.

По факту не нужно.

Я свой диплом никому и не показывал ни разу.

Знания, в ВУЗе полученные, применялись крайне редко. 95% тех знаний вообще никогда за 20 лет не пригодились.

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

Самое полезное в ВУЗЕ - это атмосфера. Эта атмосфера - это чудо.

Но не сами знания. Кроме небольшого объема базовых знаний, которые можно получить за 1-2 года больше никакой пользы нет.

ВУЗ должен подтолкнуть вас читать "лучшие практики" - это лучшее, что может сделать ВУЗ.

Все очень индивидуально.

1. Копируется все.
2. Исправляется адрес сайта в hosts локального компьютера админа. Проверяется.
3. Минимизируется запись (или вовсе отключается запись в БД).
4. Копируется БД еще раз.
5. Меняется IP в DNS.

Но в этом варианте мы не знаем когда пользователи перейдут со старого сайта на новый.

Более серьезный вариант - функционирует 2 варианта сайта одновременно.
Например, http://new.мойсайт.ру и просто http://мойсайт.ру.

С http://мойсайт.ру делается переадресация на новый сайт.

Затем применяются DNS.
Через несколько дней, когда DNS прочухаются гарантировано у всех пользователей (можно по посещаемости посмотреть) можно будет убивать старый сайт.

И делаешь обратный редирект с http://new.мойсайт.ру на http://мойсайт.ру.

Третий вариант:

Сайт изначально проектируется для работы с учетом сбоев серверов, CDN-штучками и т.п. Тогда отключение сервера ничему не грозит вообще.

Репликацию БД для первого и второго варианта не предлагаю - слишком заморочено.

Да, это нормально.

Более того - именно так и нужно делать, именно в рабочий день с утра.

Так как при переезде может возникнуть куча проблем.
И в выходной или ночью будет просто невозможно найти дополнительных специалистов/ответственных лиц датацентров/что-то срочно купить и пр.

Переезд должен начинаться в рабочий день, причем именно с утра.

Неправильно, если хостер вас об этом предупредил менее чем за неделю.
Неправильно, если вы пропустили уведомление от хостера.
Неправильно, если вы ожидаете от недорогого хостера прозрачного пеезда. Ведь даже серьезные хостеры (Гугль например) не берут на себя такие проблемы - я переезжал недавно между Гуглевыми серверами, знаю.

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

Я кажется знаю о каком хостере идет речь.
)))

Конкретно они:

1. Предупредили за 2 недели.

2. Предложили тем, для кого крайне важна безперебойная работа - специальные условия переезда (правда, со сменой IP-адреса).

Для всех же ленивых клиентов -не требуется никаких телодвижений.
Сидеть и ждать.