Philipp

Существует понятие цикла релизов. Каждый цикл подразумевает детерменированное количество изменений внесенных в продукт.
Для каждого релиза объявляется набор интерфейсов между компонентами. В разных проектах это реализуется по-разному, например в веб используются инструменты вроде Swagger.
Есть архитектор, который отвечает за общий интерфейс. Он объявляет версию, например 1.0.5. Бэкенд и фронт-энд пилятся под соответствующую версию интерфейса. Если одна команда не успевает, происходит релиз 1.0.4, т.е. то, что готово или релиз откладывается.
Обычно может быть объявлено несколько версий интерфейса.
В больших и сложных проектах используется модульный подход. Каждая команда отвечает за свой компонент проекта и имеется координатор проекта. Он отвечает за релиз. В любом случае подготовленный релиз проходит через команду тестировщиков и т.д. Просто так сырой код в продакшен не попадает.

Модифицировать код съемки и распознавания так, чтобы производился цикл съемки пока номер не распознан успешно. Не забыть ограничение по числу циклов распознавания.
Для удобства снимать вместо 1 картинки несколько с интервалом в 100-200 мс.

0. Самостоятельно заполнить 100 объявлений с проходом через регистрацию. Например перепечатать из газеты. Оценить удобство работы. Далее отозваться на половину. Посмотреть как отзыв работает. Исправить косяки.
1. Наполнить доску контентом с других ресурсов (поисковики к дублям относятся плохо, но это лучше пустого сайта).
2. Пригласить друзей/знакомых и т.д.
3. Вылизать косячки.
4. Запустить рекламу.

Добавить третью таблицу - message_status.
В ней хранить message_id, user_id и read_at в виде nullable timestamp.
В интерфейсе чата контролировать сообщения попадающие в видимую область и отслеживать событие прокрутки.
Сохранять статус сообщений в модели на клиенте и периодически отправлять эти обновления на сервер в фоне и по page unload если что-то осталось.

https://msdn.microsoft.com/en-us/library/windows/d...

Начнем с простых технических требований.
Хранение данных. В современном мире фильм среднего качества хотя бы в 720p занимает 1 GB/Hr. Т.е. 2 GB на киношку. 50 фильмов = 100 GB на жестком.

Я рекомендую остановиться на 256 GB SSD. SSD необходим по 2-м причинам - работа в автобусе предполагает значительное количество вибраций, что будет приводить к выходу из строя обычных жестких дисков, кроме этого многопоточный стриминг требует доступа к 20 различным файлам одновременного доступа на довольно значительном рейте, чего не может вам дать обычный жесткий диск.
По поводу остальной части компьютера - лучше всего брать какой-нибудь мини-компьютер без вентилятора, типа такого. Без вентилятора очень важно ибо запаритесь чистить пыль и менять вентиляторы. К компу обязательно переобразователь-стабилизатор от борт-сети автобуса. Можно такие поискать на AliExpress, но лучше найти электронщиков/радиолюбителей, они сделают все правильно.

По поводу сети получается от 2.5 MBit/s на клиента. Плюс для поддержки авторизации и странички потребуется captive portal. Для стабильной раздачи на такой скорости для такого количества клиентов обычные домашние точки доступа не подойдут, нужны точки доступа корпоративного уровня. Я советую присмотреться к двухдиапазонным точкам от Ubiquiti или Microtik. Задача точки доступа просто перенаправить человека на сервер.

В плане софта для сервера однозначно Linux, nginx + hls + mp4 streaming. Видео обязательно переконвертировать в mp4 c оптимизацией для веб. Для сервера нужно будет написать небольшой скриптик, который обойдет директории с фильмами и сгенерирует индекс плюс по небольшой страничке под каждый файл.

Поскольку в самих ПК тоже есть wi-fi, их можно настроить на подключение к домашней "межавтобусной сети". Смысл ее заключается в простой вещи. На каждый компьютер устанавливается syncthing, который будет синхронизировать ролики между компьютерами. Т.е. достаточно будет положить видео на один компьютер и все остальные синхронизируются между собой. Не очень быстро, но просто в обслуживании.

Если очень хочется современных решений, то смотрите сюда https://mobileonboard.com/beam-bus-wifi-systems/ и здесь https://www.quora.com/What-is-the-best-system-for-...
Но тема такая, что вам нужно специализированный программно-аппаратный комплекс. Увы, стоить он будет дороже автобуса. Просто по-хорошему нужно взять комп и точку доступа, собрать к ним адаптеры по питанию, засунуть все в нормальный, стойкий к вибрациям и перепадам температур корпус. Да еще и приладить к этому всему софт. Несмотря на внешнюю простоту, это сложное техническое решение.

Берите Bose.
Только надо будет немного привыкнуть к активному шумоподавлению, ибо ощущение, что оглох.

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

Мой профиль это в основном веб: JS, TS, PHP, Go, но не брезгую Ruby, Python, C++.

В общем берите MaсBook Pro, 16+ GB RAM, 512+ GB SSD, с ретиной и обычной клавой.
А если есть возможность, лучше берите 27" iMac с Retina, лучшей техники вы не найдете.

Кстати, на железе Apple винда прекрасно себя чувствует, можете сделать себе Dual Boot и пользоваться обоими ОС попеременно.

От слабого интернета не спасает ничего, кроме сильного интернета.

А теперь без шуток. В народе под слабым интернетом понимают медленный и ненадежный. Т.е. низкие скорости, ошибки передачи и обрывы в порядке вещей. Обычно такое на медленных GPRS/2G/3G соединениях. Встречается также на старых телефонных линиях, когда ADSL частенько падает.

В таких случаях загрузка видео организуется простым и надежным методом - разбивкой на части и подтверждением целостности частей.
Грубо говоря, берете файл, отрезаете от него фрагментик в 64кБ и отправляете на сервер. Если сервер за разумное время не ответил (например за минуту), рвете соединение и пытаетесь снова. Вместе с кусочком отправляете md5 этого кусочка. Сервер при приеме кусочка точно также считает md5. Если суммы совпадают, то тогда фрагментик записывается в нужное место файла.

Когда отправляются фрагменты, каждый пакет несет в себе информацию:

• идентификатор файла
  
• начало фрагмента
  
• длина фрагмента
  
• md5 сумма от фрагмента
  

Первый фрагмент дополнительно несет в себе информацию

• идентификатор файла
  
• имя файла
  
• размер файла
  
• md5 файла
  

Сервер обязан отслеживать какие части файла были загружены.

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

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

В TO-220 таких нет.

Есть вот такие IRLL110TRPBF
https://www.mouser.com/datasheet/2/427/sihll110-10...

Существует несколько способов борьбы.

Вектор усложнения доступа к информации

Информация отдается с сервера с постоянной меняющейся структурой. Например блоки меняются местами и CSS генерируется налету, причем классы собираются рандомной цепочкой и имеют абсолютно рандомные названия. Это может повлиять на SEO.
Если этого мало, то контент рендерится с помощью JS аналогичными алгоритмами. Сам JS тоже генерируется и обфусцируется. Доставка контента происходит через сложные технологии, например через WebRTC DataChannel или WebSockets. Про SEO не может быть и речи, плохо работает через мобильник.
С подобным подходом прийдется писать парсер под ваш сайт. Скорее всего он будет делать скриншот и скармливать его распознавалке.

Вектор контроля доступа к информации

Доступ к информации предоставляется определенному кругу лиц. Например клиентам. Объемы доступа регламентированы и превышение карается расторжением договора или штрафом.

Вектор ограничения доступа к информации с помощью каптчи

Для идентификации клиентов используются evercookie+fingerprinting. Используется рейтинг адресов и подсетей.
Для недоверенных подсетей (ip принадлежат в основном разного рода хостинг-провайдерам) captcha отображается сразу. Аналогично при появлении трафика из необычного места, например внезапный трафик из Индии или Китая.

Вектор "медленный сервер"

Анализируются поведенческие характеристики с помощью машинного обучения. Строится эталонная модель.
Все, кто не попадает под модель, упираются в медленный сервер. Сайт начинает отдавать контент сразу, но очень медленно, например страница может открываться секунд 30. Причем попытка параллельного запроса приводит к ошибке. Если сайт велик, то подобные штуки останавливают парсильщиков на ура. Вдобавок дополнительно контролируются определенные вещи, вроде "пользователь загрузил js и css", провел мышкой там и там.

Вектор для реального отваживания воришек

Кроме выше перечисленных способов, есть очень простые, но действенные способы. При обнаружении парсинга, парсильщику отдается неверная/искаженная определенным образом информация. Например, если есть подозрение на конкурента ворующего цены, можно отдать цены чуть выше настоящих и немного подменить название товара, например заменить определенным образом букву "а" на "a". Затем такая штука ищется поисковиком и находится сайт конкурента.
Далее вопрос решается так, как это удобно бизнесу. Обычно жалуются на нарушение копирайта. Ну или у конкурента внезапно сгорает склад. Тут уж кто на что горазд.

А это специально для любителей парсить чужие сайты: cломанные пальцы очень сильно мешают набирать на клавиатуре будьте осторожны, в большинстве случаев воровство контента того не стоит.

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

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

Читайте документацию https://developers.facebook.com/docs/pages/realtime
Там есть все необходимое.

Как насчет того, чтобы посмотреть исходники самой гориллы, в особенности тесты.

Теперь никак. Одно из правил Facebook - использование HTTPS.

Да, эти все вещи доступныm для Facebook через Graph API и т. д. Сейчас правда Facebook их сильно так урезал, надо проходить через проверку приложений.
А здесь живет API для Twitter.

Получить публикации со своей страницы через API и дальше отобразить так, как вашей душе будет угодно.

Вам не нужны аккаунты людей, вам нужна конверсия. Добавьте на свой сайт кнопку - Войти через Фейсбук, тогда пользователям будет проще зарегистрироваться и начать использовать ваш продукт/покупать ваш товар.
Чтобы увеличить конверсию, используйте Facebook Pixel и lookalike аудиторию.