Alexey Matal

Добрый день!

1. «Перенести сайт на новый движок/дизайн, но примерно сохранить структуру сайта и наполнение для страниц? (такая возмонжость есть)»

Этот вариант более реалистичен со стороны сохранения текущих позиций и поискового трафика в целом.

Для минимизации рисков потери трафика нужно :

• Желательно постараться сохранить урловую структуру основных разделов сайта (если часть урлов все-таки поменяется, не забыть настроить 301 редиректы со старых страниц на новые);
  
• Желательно сохранить контент: мета-теги, заголовки (H1-H5) и тексты страниц (структуру подачи текстового контента менять можно – не страшно);
  
• Новые страницы нужно делать с учетом адаптивной верстки, т.к. сейчас больше трети пользователей заходит в интернет с мобильных устройств;
  
• Минимизировать время загрузки страниц (важно с точки зрения пользовательской лояльности и со стороны поисковых систем);
  
• Сделать контент по возможности в HTM-коде (исключить технологии AJAX, фреймов, FLASH, JavaScript и т.д., которые затрудняют индексацию страниц поисковыми роботами).
  

При условии, что Вы выполните все вышеописанные работы, все равно есть некоторый риск проседания трафика примерно на 20%. Но данная ситуация исправится через 1-2 месяца.

2. «Если кардинально менять дизайн: многостраничный сайт из начала 00-х -> современный лендинг?»

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

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

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

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

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

В "современных" ГОСТах ЕСПД и ГОСТ 34 нет понятия дистрибутива, на сколько я знаю.
Но вам никто не мешает ввести это понятие самому, описать процедуру установки ПО в рамках документа "Описание программы" или "Описание применения", в руководстве программиста или системного программиста описать процедуру создания дистрибутива.

Вкратце:
Ответы
1. Не совсем, но, думаю, скоро будет понятно
2. Соединение всегда открыто, если одна из сторон его не закроет или не прервется связь
3. Клиент отправляет - сервер тут же получает. Сервер отправляет - клиент тут же получает.

На примере чата
1. Устанавливается соединение между сервером и клиентом 1 (handshake)
2. Сервер -> клиент1: Вы присоединились к чату
3. Сервер -> клиент1: Сейчас у нас 1 пользователь: клиент1
4. Устанавливается соединение между сервером и клиентом 2 (handshake)
5. Сервер -> клиент2: Вы присоединились к чату
6. Сервер -> клиент2: Сейчас у нас 2 пользователя: клиент1 и клиент2
7. Сервер -> клиент1: Присоединился клиент2
8. Клиент1 -> сервер: Скажи клиент2 "Привет!"
9. Сервер -> клиент2: Клиент1 сказал "Привет!"
10. Клиент2 -> сервер: Скажи клиент1 "Здасте!"
11. Сервер -> клиент1: Клиент2 сказал "Здасте!"

То есть клиенты могут когда угодно посылать сообщение серверу, он сразу же его прочитает, но не другим клиентам (минус сокетов). Сервер может послать сообщение любому клиенту, они сразу же его прочитают.

WebSocket - постоянное соединение поверх http(s)
При установлении соединения происходит рукопожатие с помощью специальных http заголовков, после любая сторона в любой момент времени (пока соединение не прервется) может писать в тело запроса сообщения. Каждое такое сообщение представляет из себя передаваемые данные + мета-данные

1. Можно найти сходство с tcp, только вместо пакета у нас сообщение. Так как ws работают поверх http, который в свою очередь работает поверх tcp, то формально одно сообщение может быть разбито на несколько tcp пакетов, а в одном пакете может содержаться несколько сообщений, однако единицей данных для ws является именно сообщение
2. ws - это постоянное соединение, которое будет висеть пока любая из сторон не закроет его либо пока не оборвется связь. Так как сокет формально может простаивать (когда нет обмена данными), то tcp соединение для него нужно открывать с опцией keep-alive, а так же желательно отправлять http заголовки для keep-alive в рукопожатии.
3. Любая сторона может в любой момент времени может отправить любое количество сообщений. Получающая сторона получит данные, когда до нее дойдут все tcp пакеты самого раннего из сообщений (это гарантирует, что сообщения придут в том же порядке, в котором они были отправлены)

Считаю, что тестовые сценарии пишутся по ТЗ если цель - приемочное тестирование. Если же цель Quality Assurance, то тестовые сценарии пишутся на основе опыта самого инженера тестирования, а он в свою очередь отталкивается от своих личных предпочтений и лучших практик по рынку или по сегменту. Для примера, в ТЗ могут не описываться ошибки валидаций на POST запросы, а хороший QA может их придумать сам уже на уровне кейсов, при этом подкинув работы разработчикам но и увеличив качество продукта в итоге. Вот я вижу эти два пути. Приемка и Quality Assurance.

Угу. Тогда действительно лучше хранить деревом в виде Nested Set.