latteo

Привет,
1. Внутрикамерная обработка в JPG зависит от настроек камеры (баланс белого, резкость, тип снимка и т.п.) и после нажатия кнопки в камере создается RAW (сырой снимок) и сразу за ним процессор камеры, используя эти установки формирует JPG. В зависимости от модели камеры может быть сохранен только JPG или только RAW или RAW+JPG.
2. Вместе с камерой распространяется и программа, к примеру, DPP у CANON, которая фактически, может делать JPG из RAW автоматом, используя именно те установкам камеры, которые были определены при съемке. Если автомат не удовлетворяет, то можно самостоятельно покрутить всяческие бегунки и "вытянуть" RAW, как душе захочется. Но, внутри программ от производителей есть возможность автоматизировать обработку и в пакетном режиме, как по установкам камеры, так и по своим. Создали некий алгоритм "вытягивания" и потом применили его к куче RAW-ов.

А "блеклый" RAW потому, что там, грубо говоря, "все в нулях" - это сырой снимок. Делаете, к примеру, резкость = 5, насыщенность = 7 и т.д. и RAW уже становится не "блеклым".

P.S. Играться с RAW можно "до одури" :-) и через некоторое время это надоедает настолько, что снимать в RAW практически перестаешь.

Настройки->Wifi->Расширенные настройки->Установка сертификатов

Вот пример с алгоритмом Programming Classics: Implementing the World's Best Algorithms by Oliver (ISBN 0-131-00413-1). Есть еще другие реализованные алгоритмы в php, почитайте здесь levenshtein и здесь soundex. Либо можете написать свой алгоритм.

$searchPhrase = "Поиск строки 14";
        $words = ['Поиск строки 14', 'рандомный текст 14','строки 14'];

        $wordsWithSimilarity = [];
        foreach ($words as $word) {
            $similarity = similar_text($searchPhrase, $word);
            $wordsWithSimilarity[$similarity] =$word;
        }

        krsort($wordsWithSimilarity);

1. Процесс упадет.
2. Система не загрузится, если нет свободного места на диске.

Для того, чтобы избежать такую проблему нужно научиться делать шардинг. Поэтому читаем:
1. Пофиг, что MySQL, важно понять принцип https://ruhighload.com/post/%D0%A8%D0%B0%D1%80%D0%...
2. Старая версия (она подробнее) https://docs.mongodb.com/v3.0/core/sharding-introd...
3. Новая https://docs.mongodb.com/manual/sharding/

Привожу живой пример из личной продакшн практики. PHP-CLI скрипт как запускаемое приложение
Начальные условия:
Наличие GNU Linux (в моём случае это Debian)
Установленные пакет php, php-cli, остальные по вкусу и зависимостям
В качестве таймера используется класс React\EventLoop\Factory
1. Создаём пустой файл, можно без разрешения (например daemon), открываем в текстовом редакторе
Важно, чтобы в начале была строка #!/usr/bin/php -q
2. Пишем

#!/usr/bin/php -q
<?php
ini_set("display_errors", 1);
error_reporting(E_ERROR);
require "/var/project/vendor/autoload.php";
require '/var/project/bin/cli_config.php';
use Ratchet\Session\SessionProvider;

$loop = React\EventLoop\Factory::create();
//вызовы $loop->addPeriodicTimer можно ставить в нужном количестве, первый параметр - количество секунд
$loop->addPeriodicTimer(120, function(){
//код здесь будет выполняться каждые 120 секунд
});
//если нужен повторяющийся цикл 
//$loop->run();
//а если нужен один раз на вызов
$loop->tick();

3. chmod a+x /www/project/bin/daemon - даём права на выполнение
4. запускаем ./daemon будучи в папке с файлом. Если ошибок нет, всё будет работать
5. А ещё скрипт можно установить как демон в systemd и управлять с помощью /etc/init.d/daemon.service (start|stop|restart) и есть ещё bash-скрипт который будет держать службу на контроле и перезапускать если что, так как не всегда ошибка возвращает код и systemd считает, что процесс не упал, а его остановили, но это уже другая история

6. Для решения задачи "Требуется по запросу юзера (нажал кнопку) вести отсчет таймера от 120 секунд до 0 и произвести действие" в php на действие пользователя просто запустить exec('/var/project/daemon', $output_1, $exitval);

Бекенд - делает серверную логику,
Фронтенд - делает клиентскую логику,
Верстальщик - верстает сервис, по макету, нарисованному дизайнером
Дизайнер - рисует дизайн сервиса

По 1му каждый. Можно убрать верстальщика и оставить только фронтенд разработчика, при условии, что тот умеет верстать(хотя, он должен уметь верстать, но, некоторые уже не любят этим заниматься).

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

Порядок действий.
1) Описали всю логику сервиса, ПОЛНОСТЬЮ, до мельчайших деталей, прям каждую писечку!!!! Всё всё всё. После прочитать раза 3 от начала до конца, 100% появятся правки или дополнения. Все функции по монетизации, тарифы, личные кабинеты, конструктор самого окна, функционал вставки этого окна и всё всё всё. Ибо никто не станет вам на добром слове вносить изменения в созданную прогерами архитектуру проекта, потому что вы, не удосужились вписать новое требование в тз. С вам, что логично, потребуют доп плату уже к той, что была оговорена в начале.

2) Ищите дизайнера. Нашли? Отлично! Тогда:
1.1) По вашему тз делается прототип, того, что и как будет расположено на сайте, где какие элементы. Это как первые наброски, чертёж, если угодно.
1.2) На основе этих набросков рисуется макет, утверждается дизайн сервиса.
1.3) Утвердили все страницы, все элементы, все всё всё. У вас уже есть то, как выглядит ваш сервис.

3) Берём фронтенд разработчика + бекенд разработчика
Тут нужно подойти ответственно. Хорошего разработчика порой трудно найти, часто, хорошие стоят дорого, дешёвые сделают тяп ляп и ваш сервис станет очень сложно менять и дополнять в будущем.

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

Сам план работ, лучше разделить на этапы с вашей стороны. Т.е. Сделали один функционал, проверили, ещё 1 проверили. Разделить всё на задачи. Вам от этого только лучше, т.к. вы видите, что уже реализовано и сам факт того, что процесс идёт. Но повторюсь, нужно эти этапа с прогерами обсудить и принять.

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

4) Тестирование
Все всё сделали, ура. Дальше, начинаем тестировать сервис на его функционал. Ошибки и баги будут 100%. Все мы люди, все можем ошибиться, нужно эти ошибки исключить.

5) Выкатка приложения:
Т.к. сайт делался на дев(там, где разрабатывают) версии, осталось выложить сайт на основной домен(Который вы должны ещё приобрести). Выложили, всё настроили, ура. Приложение готово. Далее, реклама, маркетинг, сео и прочая чушь.

P.S. Так как всё это пахнет фрилансом, то будьте готовы, что вас могут кинуть, игнорить, пропадать не известно куда. Не забудьте составить договора с прогерами, где будут описаны все нюансы. А так же, что бы под конец все права принадлежали вам и только, получение всех доступов, данных и т.п. Иначе потом, можете всё похерить и никто вам уже не поможет.

Примерно так))

Tour, wizard, steps, etc - это всё инструменты, частные варианты.

Этот процесс называется Onboarding.
Поэтому можно гуглить что-то из серии "web site onboarding best practice"

Примерно так должно работать.

server {
  listen 80 default_server;
  listen [::]:80 default_server;
  return 444;
}

server {
  listen 80;
  listen [::]:80;
  server_name  vashdomain.com;

  error_page  403 /error/404.html;
  error_page  404 /error/404.html;
  error_page  500 502 503 504 /error/50x.html;
  
  location / {
    proxy_pass http://127.0.0.1:4567;
    proxy_http_version 1.1;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_cache_bypass $http_upgrade;
  }
}

Через удалённое подключение, к сожалению, уже никак.
Если с микротиком в одной сети, то через мак адрес к нему получится подключиться ещё, и исправиться.
Вторая вкладка в winbox, Neighbors.