Как запоминать иностранные слова и выражения

Тема заезженная, понимаю. Но, как человек, добившийся выдающихся успехов в развитии вокабуляра при СРЕДНЕЙ памяти, позволю себе несколько слов. Каждый запоминает информацию очень по-разному, это зависит от целого ряда индивидуальных особенностей — преподаватели тут особо не помогут. Не верьте рекламе, никаких универсальных методик запоминания не существует, каждый должен изучить работу своей памяти самостоятельно. В целом наша способность запоминать опирается на 2 столпа:

  • Эмоции (у него сложная фамилия, но я запомнил легко, потому что мне кажется, что она забавно звучит)
  • Ассоциативные связи (у него сложная фамилия, но я запомнил легко, потому что похожая была у моего одноклассника).

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

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

Когда мы спим, мозг фильтрует информацию, полученную за день, на предмет её отношения к «выживанию». К выживанию он по умолчанию относит всё, что несёт эмоциональную нагрузку. Если информация вызывает эмоции, он принимает решение её сохранять. Не вызывает эмоций — удаляет. И чем более яркие эмоции (неважно даже — отрицательные или положительные) привязаны к информации, тем более приоритетной эта информация будет в глазах нашей психики (экстремальный контекст вытеснения травматических воспоминаний в расчёт не берём).

Представьте, что вы выходите из своей квартиры и видите на лестничной клетке человека с ножом. Он просто пришёл к соседу нож поточить — ну нет у него точильного камня! Эту ситуацию вы запомните надолго, если не навсегда. Мозг присвоит ей наивысший приоритет относительно важности для выживания.

Вопреки распространённому мифу, языковая среда не даёт никаких чудес. Точно так же приходится запоминать каждое слово и выражение. Но там произносимые фразы имеют прямое отношение к реальным ситуациям и людям. Это обеспечивает им мощную эмоциональную нагруженность, и, как следствие, более высокий приоритет в глазах нашей психики. Если вы у себя дома и читаете в разговорнике Could you tell me how to get to Trafalgar Square? (Как добраться до Трафальгарской площади?), эта фраза не запомнится. А вот если вы мечетесь посреди Лондона, и вас ждут на этой площади, шансов запомнить её гораздо больше.

Не случайно же мы помним в деталях огромное количество бессмысленных, на первый взгляд, ситуаций и диалогов из прошлого — на них нанизано огромное количество ассоциаций, к тому же подкреплённых эмоциями.

По этой же причине самостоятельные занятия по учебникам обычно дают более низкий результат, чем живое взаимодействие с преподавателем. Информация из учебника не нагружена эмоционально, не имеет прямого отношения к насущным проблемам, поэтому психика считает, что её надо стирать. И плевать она хотела на то, что у вас важный экзамен. Умом мы понимаем, что информация из учебника гораздо более важна, но психика — как глупый подросток: есть смешные картиночки — интересно, сохраняем. Нету — безжалостный игнор.

ЛАЙФХАК: Психику, озабоченную проблемой «выживания», легко обмануть. Если выделять 5-10 минут ежедневно на повторение пройденного материала, её можно убедить, что иностранный язык актуален для выживания — часто встречающиеся единицы информации она тоже воспринимает как что-то важное и сохраняет в памяти.

Эмоционально нагруженные ситуации можно и нужно использовать для запоминания идиом. Когда рядом с нами появляется какой-то человек, сразу же начинается эмоциональное взаимодействие, даже если нет никаких слов или жестов. Даже незнакомый. Даже на другом конце пустого вагона метро. Мы начинаем на всех уровнях принимать во внимание присутствие этого человека.

Взаимодействие с другими людьми — это неиссякаемый источник эмоционально нагруженных ситуаций. Эксплуатируйте это по полной программе! Вплоть до того, что, возвращаясь вечером с работы, можно вместо «добрый вечер» озвучить домашним английскую идиому. В ответ на недоумевающий взгляд дать перевод этой идиомы и объяснить, зачем это было нужно. Посмеялись, обменялись положительными эмоциями, надолго запомнили саму ситуацию и, с высокой вероятностью, собственно идиому. Но нельзя один и тот же приём использовать с большим количеством материала. Одна идиома — одна непохожая на другие ситуация.

Представьте, что вы встречаете знакомую, которую долго не видели. Привет-привет. Ты знаешь, говорит она, я хожу на курсы английского! Запомнила сегодня 5 новых слов — и вываливает на вас эти пять слов с переводами. Запомните вы только то, что двинулась она, похоже, на этих курсах. Несколько не связанных друг с другом слов — слишком большой объём материала для одной ассоциации. А вот если она скажет: «Слушай, классное выражение на английском выучила: And Bob’s your uncle! Аналог нашего «И готово!». Вы потом будете годами вспоминать эту ситуацию и, с высокой вероятностью, саму идиому.

Приёмы для эксплуатации жизненных ситуаций с целью запоминания иностранных выражений могут и часто должны быть нестандартными. Вариант: один раз в жизни написать на руке плохо смывающимся маркером одну короткую идиому. Этот опыт вы будете помнить годами. Возможно, сама идиома также осядет в памяти. Часто используемые контакты в телефоне имеет смысл переименовать в простые существительные или прилагательные — вы постоянно будете утыкаться в них взглядом, возникнет ассоциация между этим человеком и данным английским словом. Пароли на имейлах и в социальных сетях совершенно необходимо сделать идиомами. Зачем захламлять свою память бессмысленным Lenusik87, когда, например, есть полезное, распространённое выражение under no circumstances, к тому же содержащее сложное по написанию слово? Повводите на разных устройствах пару лет подряд — ничем потом не вышибешь из памяти. Разумеется, это лишь вспомогательные приёмы — на одних переименованиях контактов в телефоне далеко не уедешь. Изучайте работу своей памяти!

image

ссылка на оригинал статьи https://habr.com/ru/post/495030/

Простой Telegram-бот на Flask с информированием о погоде

Всем привет, в этой статье я расскажу как сделать простейшего телеграмм бота на Python для отправки текущей погоды в Москве.

Статья расчитана на новичков в Python, которые бы хотели узнать больше о том, как взаимодействовать с внешними сервисами по API.

Технологии и API:

  • Python — язык программирования,
  • Flask — фреймворк для создания веб-приложений,
  • Telegram Bot API,
  • Weatherstack API,
  • Ngrok — сервис для создания туннеля к localhost.

Как все будет работать?

  1. Пользователь пишет сообщение телеграмм боту.
  2. Telegram пересылает сообщение пользователя на сервер.
  3. Сервер запрашивает информацию о погоде у Weatherstack.
  4. Сервер отсылает информацию о погоде в Telegram.
  5. Пользователь получает информацию о погоде.

Регистрация телеграмм бота

На этом этапе нам нужно создать бота и получить к нему доступы. Для этого запускаем бота @botfather в Telegram командой ниже.

/start

Создаем нового бота согласно инструкциям из сообщения от бота.

Регистрация телеграмм бота!

Бот создан, но если ему написать какое-нибудь сообщение, он никак на него не отреагирует. Исправим это.

Справка о Flask

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

Поддерживается установка посредством пакетного менеджера PyPI, версия 1.0 совместима с Python 2.7, Python 3.3 и выше.

Источник.

Установка Flask

Для изоляции зависимостей пакетов Python создадим папку проекта и виртуальное окружение. Для этого в терминале выполним команды ниже. Подробнее о виртуальных окружениях.

$ mkdir weather_bot $ cd weather_bot $ python3 -m venv venv

После завершения установки и активации виртуального окружения установим Flask.

(venv)$ pip install Flask

Подробнее на странице Installation.

Запуск простейшего приложения Flask

В директории weather_bot создадим файл app.py с содержимым.

from flask import Flask app = Flask(__name__)  @app.route('/') def hello_world():     return 'Hello, World!'

Запустим полученное приложение.

(venv)$ export FLASK_APP=app.py (venv)$ flask run  * Running on http://127.0.0.1:5000/

Перейдем по адресу http://127.0.0.1:5000/ и убедимся, что отображается текст "Hello, World!".
Подробнее на странице Quickstart.

Создание туннеля к localhost с помощью ngrok

Ngrok — это сервис, позволяющий создавать туннели на локальный компьютер пользователя.

  1. Зарегистрируемся на сайте ngrok.
  2. Выполним установку по инструкции.
  3. Запустим HTTP туннель на 5000 порту с помощью команды терминала ниже.

$ ./ngrok http 5000

Получение сообщений из телеграмм бота

Для того, чтобы Telegram пересылал сообщения на наш сервер, нужно передать сообщить ему адрес сервера. У нас уже создан туннель, поэтому его передадим адрес в Telegram. Это делается с помощью метода POST setWebhook. Подробнее на странице документации.

$ curl --location --request POST 'https://api.telegram.org/bot{token}/setWebhook' \ --header 'Content-Type: application/json' \ --data-raw '{     "url": "{url}" }'

где {token} — токен вида 840446984:AAFuVTW-FYP5tJVu8mqhc9y4E0j1fr2lCD0, который нам прислал BotFather,
{url} — адрес вида https://32515a83.ngrok.io, который отобразился в консоли ngrok. Обратите внимание на протокол. Он должен быть https, иначе Telegram не примет url.

Подробнее о cURL на странице wiki.

Если получен ответ "ok": true, то все в порядке.

{     "ok": true,     "result": true,     "description": "Webhook was set" }

Проверим, что сообщения доходят до нашего локального сервера. Для этого в файле app.py обновим код.

from flask import Flask, request  app = Flask(__name__)  @app.route("/", methods=["GET", "POST"]) def receive_update():     if request.method == "POST":         print(request.json)     return {"ok": True} 

Перезапустим Flask. Для этого остановим сервер из терминала комбинацией клавиш Ctrl+C и повторно запустим сервер.

(venv)$ flask run

Отправим нашему боту сообщение с произвольным текстом. В консоли должно отобразиться тело запроса из Telegram. Это признак того, что все в порядке.

Сообщение в консоли!

Ответ на сообщения пользователей

Мы научились получать сообщения от пользователей, но еще не умеем их отправлять. Для проверки отправки сообщений будем отвечать текстом "pong" на все сообщения.

Для отправки сообщений пользователям в API Telegram используется метод sendMessage. Подробнее на странице документации.

Запросы будем делать с помощью библиотеки requests, которой нет в списке стандартных, поэтому установим ее. Для этого в терминале с активированным виртуальным окружением выполним команду нижу.

(venv)$ pip install requests

Добавим строку импорта requests сразу за строкой from flask import Flask, request в app.py.

import requests

Для отправки сообщений нам нужно знать id чата. Его можно вытащить из тела Telegram-запроса.

chat_id = request.json["message"]["chat"]["id"]

Напишем функцию для отправки сообщений, в которую будем передавать id чата и текст сообщения.

def send_message(chat_id, text):     method = "sendMessage"     token = "840446984:AAFuVTW-FYP5tJVu8mqhc9y4E0j1fr2lCD0"     url = f"https://api.telegram.org/bot{token}/{method}"     data = {"chat_id": chat_id, "text": text}     requests.post(url, data=data)

Подробнее о библиотеке requests на странице.

Добавим вызов функции send_message() из receive_update().

send_message(chat_id, "pong")

Вот так выглядит код в файле app.py

from flask import Flask, request import requests  app = Flask(__name__)  def send_message(chat_id, text):     method = "sendMessage"     token = "840446984:AAFuVTW-FYP5tJVu8mqhc9y4E0j1fr2lCD0"     url = f"https://api.telegram.org/bot{token}/{method}"     data = {"chat_id": chat_id, "text": text}     requests.post(url, data=data)  @app.route("/", methods=["GET", "POST"]) def receive_update():     if request.method == "POST":         print(request.json)         chat_id = request.json["message"]["chat"]["id"]         send_message(chat_id, "pong")     return {"ok": True}

Отправка пользователю информации о погоде

Используем метод current Weatherstack API для получения информации о погоде.
Передадим 2 обязательных Query Params: access_key — секретный ключ вида 86a3fe972756lk34a6a042bll348b1e3, который можно получить после регистрации, и query — город, по которому получаем информацию о погоде, в нашем случае — Moscow.

Подробнее на странице документации.

Добавим функцию для получения текущей температуры в Москве после строки app = Flask(__name__).

def get_weather():     params = {"access_key": "86a3fe972756lk34a6a042bll348b1e3", "query": "Moscow"}     api_result = requests.get('http://api.weatherstack.com/current', params)     api_response = api_result.json()     return f"Сейчас в Москве {api_response['current']['temperature']} градусов"

Внутри функции receive_update() вместо сообщения с текстом "pong" передадим погоду.

weather = get_weather() send_message(chat_id, weather)

Код всего Flask-приложения состоит из 3 функций: получения сообщений из Telegram, отправка сообщений в Telegram и получение информации о погоде из Weatherstack.

from flask import Flask, request import requests  app = Flask(__name__)  def get_weather():     params = {"access_key": "86a3fe972756lk34a6a042bll348b1e3", "query": "Moscow"}     api_result = requests.get('http://api.weatherstack.com/current', params)     api_response = api_result.json()     return f"Сейчас в Москве {api_response['current']['temperature']} градусов"  def send_message(chat_id, text):     method = "sendMessage"     token = "840446984:AAFuVTW-FYP5tJVu8mqhc9y4E0j1fr2lCD0"     url = f"https://api.telegram.org/bot{token}/{method}"     data = {"chat_id": chat_id, "text": text}     requests.post(url, data=data)  @app.route("/", methods=["GET", "POST"]) def receive_update():     if request.method == "POST":         print(request.json)         chat_id = request.json["message"]["chat"]["id"]         weather = get_weather()         send_message(chat_id, weather)     return {"ok": True}

Вот и всё! Таким несложным образом мы научили наш бот информировать нас о погоде в Москве.

ссылка на оригинал статьи https://habr.com/ru/post/495036/

Почему в мозгах есть баги?

Когда мы используем любую программу, у нас есть две причины для получения неправильных результатов:

  • Неправильные/недостаточные входные данные. Если на входе программа получает бред, на выходе мы тоже получим бред, даже если внутри все отработало идеально. Такой концепт называется Garbage In, Garbage Out. Исправить это мы не сможем — проблема не в программе.
  • Из правильных данных мы получили неправильный ответ. Тогда мы считаем, в программе есть баг и пытаемся его чинить.

Тоже самое можно сказать и про нас.

Иногда необходимая информация — отсутствует и мы не можем предотвратить ошибку.
Например, мы даем оценку времени на решение какого-то списка задач. В процессе оказывается, что список должен был быть в 3 раза больше. Ожидаемо, что наша первая оценка будет ошибочна. От нас здесь ничего не зависело. Garbage In — Garbage Out.

Но если мы уже 20 раз подряд наблюдали как количество задач вырастает в 3 раза от начального, странно предполагать, что на 21-й раз все пойдет как по маслу.

Если бы моя программа 20 раз подряд выдала результат, который не совпал с реальностью, я бы предположил, что с ней что-то не так. Зачем она мне, если при ее использовании я все равно получаю неверный ответ? Она должна учитывать факт, что количество задач может вырасти. Ее надо починить и адаптировать к таким условиям работы.

Когда я наблюдаю такую ошибку за собой — я делаю тот же вывод.

Ситуация, описанная выше — называется «Ошибкой планирования». Она — один из пунктов большого списка «Когнитивных искажений». На эту тему много статей, книг, ресурсов — но ни один из них не ответил на мой простой вопрос: «Откуда ошибки берутся и как лучше их исправлять?». Что не так с мозгом, что он предсказуемо выдает неверные результаты? Как накатить на это патч? Если так нельзя, то где подпирать костылями?

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

С чем мы работаем

Для начала оговорюсь, что устройство мозга очень отличается от PC. Ничего приблизительно напоминающего SSD, RAM и CPU — в нем нет. Ближайший аналог — видеокарта или вычислительный кластер.

Каждый нейрон — это маленькая вычислительная машинка. Принимает кучу сигналов на вход и по их совокупности вычисляет, когда и как отдать сигналы на выход. Таких штук в человеческом мозге примерно 86 миллиардов, у каждой — тысячи соединений (синапсов), каждое соединение — со своими параметрами (подробнее про основные особенности работы нейронов).

Короче, если представить видеокарту с 3d упаковкой ядер в количестве 86 миллиардов, где каждое ядро соединено с тысячами других — мы получим очень грубую, работающую совершенно не так, модель мозга. Ну а CPU тут вообще не годятся.

Кстати, это ответ на вопрос, почему ИНС быстрее обучаются на видеокарте. Отдельный нейрон моделировать не сложно, но нам нужно обсчитывать огромное их количество. Решение — считать параллельно.

Но как же память?

А память в такой архитектуре — очень интересная штука. Вместо того, чтобы хранить какие-то «адреса» и читать блоки, мозг сохраняет информацию о том, как вычислять ответ на сигнал. Это больше похоже на запрос в Гугл, нежели на чтение с SSD. Минусы — нельзя обратиться к адресу напрямую и быстро прочитать данные. Плюсы — можно вспомнить «тот фильм, в котором парень с бородкой, в красно-золотом костюме из металла, спасал мир». (Подробнее про память)

У вас мог возникнуть вопрос, связанный с тем, почему мы воспринимаем наши размышления не как кучу происходящих параллельно процессов, а последовательно. Это связано с особенностями работы префронтальной коры и внимания. О них я напишу отдельную статью. Пока что они нам не нужны, но для объяснения такого явления как "поток" — понадобятся.

Как возникают ошибки?

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

Сила связей и память

Эффект силы связей

Состояния большинства связей в мозге, ответственных за память — возвращаются к исходным за часы/дни. Когда мы встречаем проблему, с которой сталкивались давно — у нас очень небольшие шансы на извлечение информации о ней. Зато, если мы совсем недавно столкнулись с такой проблемой — связи неимоверно сильные. Настолько, что мы будем видеть эту проблему везде, даже если она встречается 1 раз на миллион и не стоит такого количества внимания. А уж если она случайно встретиться второй раз, то ее приоритет поднимется выше Tesla Roadster, запущенного SpaceX.

Думаю, вы уже связали эту информацию с ошибкой планирования. Да, мы склонны учитывать только свежий опыт. Чтобы посмотреть дальше — нам нужно приложить много усилий.

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

Корреляция — не есть причинность

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

А когда мозг делает какой-то вывод — он старается его запомнить и поддержать силу связей.

Ложное понимание

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

В том что мозги устроены так — нет ничего плохого. Да, они заточены под нахождение паттернов, и да — у них иногда получается не верный результат. Просто нужно помнить, что некоторые наши шаблоны — неправильны и уметь это распознать.
Ситуация осложняется тем, что мозг уже построил связи и не выдает нам пустой ответ. У нас не будет чувства, что мы «ничего не поняли». Но модель, которая получится в результате — будет неверной. Более того, поскольку у нас уже есть эта модель — мозг будет выбирать ее, а не попытается построить новую.

Как это исправить?

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

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

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

Чтобы детектировать, что мой мозг где-то меня нагрел, и подсунул иллюзию понимания я использую такой прием:
Я пытаюсь описать то, что я должен был понять переводя в другю систему терминов. По сути — используя аналогии. Например, если я могу описать, что такое Реактивное Программирование используя термины из математики, или на примере того, как течет вода — я скорее всего его понял (эта концепция отлично описывается заварочными чайниками, соединенными трубками — я так девушке объяснял).

Второй вариант — менее приятный. Наш шаблон должен сломаться, в результате того, что мы хорошенько сели в лужу. Например, мы привели всех своих друзей к «волшебной двери», но ключ ни у кого не упал. И у нас тоже. Тут есть способы попытаться оставить шаблон, например: «Вы недостаточно верили в магию двери! Поэтому она не работала!» — о таком механизме мы поговорим дальше.

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

Список когнитивных искажений (Память и связи):

Лучше всего его использовать так:

  1. Ткнуть в понравившееся название.
  2. Почитать про этот феномен.
  3. Попробовать вспомнить, встречали-ли вы похожее поведение в жизни.
  4. Попробовать объяснить эффект из списка, с помощью информации из этой статьи.

Не пытайтесь его выучить. Само не запомнилось — ну и черт с ним. Главное — попробовать понять, как это явление согласуется с тем что происходит в мозге, и тем, что мы сами наблюдаем. Лучше всего будет если вы поделитесь своими выводами в комментариях — может получиться интересное обсуждение.

Генерализация частных случаев.
Феномен Баадера-Майнхов.
Проклятие знания.
Профессиональная деформация.
Предвзятость относительно экономии времени.
Ошибка планирования.
Иллюзия прозрачности.
Фундаментальная ошибка аттрибуции.
Эффект ореола.
Эффект первого впечатления.
Эффект опозноваемой жертвы.
Ошибка игрока.
Иллюзия кластеризации.
Эвристика доступности.
Ошибка выжившего.
Стереотипизация.
Эффект недавнего.
Каскад доступной информации.
Функциональная закрепленность.
Эффект знания задним числом.
Иллюзорная корреляция.
Эффект привязки (якорение).
Эффект телескопа.
Криптомнезия.
Ложная память.
Эффект дезинформации.
Эффект уровня обработки.

Было бы просто прекрасно, если бы список на этом и кончался, но у нас есть еще один большой пласт проблем.

Отложенное обучение и игнорирование

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

Если мы пытаемся сделать программу, отличающую кошек от собак — мы заставляем ее угадывать, какую картинку ей дали на вход. Когда программа ошибается — мы пытаемся внести изменения в ее структуру (например, ослабить связи для активных «нейронов» в ИНС). Когда все хорошо — мы должны зафиксировать текущее состояние (например, услилить активные связи).
Если мы даем ответ о правильности распознования сами — мы выступаем учителем. Если мы построили программу так, что каждый раз когда она делает предположение, она самостоятельно проверяет его — у нас обучение без учителя.

Мозг — пример системы, которая умеет обучаться самостоятельно.

Фидбек извне

Давайте вернемся на много лет назад, когда мозги решали простые проблемы. Например: «Как достать с пальмы кокос». Предположим, мы пришли к выводу, что надо потрясти пальму, кокос упадет и мы позавтракаем. Мы трясем пальму, кокос падает нам на голову. Теперь вместо завтрака у нас огромная шишка на голове и нам больно.

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

А теперь вернемся в наше время. Всю неделю мы работали над Важными Задачами. Мы успели завершить все к пятнице. Вечером мы пошли в бар, затем классно провели выходные, выехали на природу, позанимались любимым хобби.

Придя на работу в понедельник мы видим коллегу, который с порога говорит нам: «Что это за хрень ты сделал?».

Бац! На нас только что упал воображаемый кокос. Механизм примерно тот-же: мы собирались спокойно прийти на работу, выпить чаю, сесть за задачи. А вместо этого какой-то *** сбивает нам все планы, и собирается на нас наехать! Вот редиска, да? Надо осадить этого парня, чтобы выпить чаю, и нормально приступить к задачам. Он что, не понимает, что у нас на носу дедлайн, сейчас вообще не время такой фигней страдать? Работать нужно!
Мы отвечаем что-то резкое, чтобы от нас отстали.

В этот момент в голове того парня: «О боже, он непроходимый идиот. В его задаче, которую он делал во вторник грубейшая ошибка, которая будет нам дорого стоить. Но он и слушать об этом не желает!» — Заметим, теперь и нашего коллегу ушибло ментальным кокосом. — «Скажу этому выскочке, что из-за его нежелания меня слушать он угробит весь проект, может хоть тогда прислушается?»

Обмен кокосами может продолжаться довольно долго.

Чем эта ситуация отличается от привычной для мозга тряски дерева?

Во первых — мозг нифига не понимает, за что в него сейчас полетел кокос. Представьте, что мироздание внезапно заработало по другой схеме и теперь удар по голове происходит через неделю, после того как мы неудачно потрясли дерево. Да мы уже 5 раз успеем забыть что его трясли.

Когда мозг нифига не понимает — он пытается подобрать подходящее объяснение. (Подробнее можно почитать в этой статье) А какое самое подходящее объяснение кокосу который в вас кинул другой человек? Правильно, — этот человек — *** и склонен во всех кидать кокосы.

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

Опаньки, мозг сделал неверный вывод, тем же механизмом который привел нас к ошибочной «теории ключа и двери». Вместо того, чтобы проанализировать всю цепочку и понять причину — мы довольствуемся корреляцией.

А теперь, основываясь на своей «великолепной» идее, мозг сделает еще одну донельзя логичную вещь: попытается решить проблему летящих в него кокосов. А какое тут самое очевидное решение? Правильно, — надо избавиться от «кокосометчика». Хорошо, если «избавиться» будет означать простое игнорирование и уход в закат. Но это же НЕСПРАВЕДЛИВО! В нас же первого кинули кокос и для ровного счета нужно вернуть его бросавшему. Он сам должен признать, что был неправ начав кидать в нас кокосы.

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

Самое забавное во всей этой ситуации, что обычно «победителем» признается тот, кто кинул последний кокос. Хотя, на самом деле, чем больше мы с коллегой находились в цикле, тем больше шишек получали вдвоем.

Фидбек изнутри

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

Предположим, мы разошлись с коллегой ничего не прояснив. Теперь нам неприятно об этом вспоминать. Мозг уже сделал вывод, что наш коллега — злобный кокосометчик, поэтому решение «попробовать спокойно поговорить и разобраться» — выглядит совсем непривлекательно. Но с неприятным ощущением нужно что-то сделать.

Ух ты, у нас есть одна отличная стратегия, сработавшая с коллегой — игнорировать. Или переключиться на что-то другое. Отличный выход, правда? Нужно просто вести себя как ни в чем ни бывало. Подумаю о чем нибудь приятном и сделаю кружку хорошего чая. А это все — как-нибудь само рассосется.

Помните, в начале текста я говорил, что ошибки бывают двух типов? Один из них — ошибки обработки информации. Другой — ошибки вызванные ее искажением или недостатком. И только что мозг ухитрился вляпаться в ошибку второго типа. Теперь вместо полной картины он видит только самый приятный ее кусочек, начисто игнорируя варианты в которых «не рассасывается».

В эту лужу я нырнул с головой лет 7 назад и с удовольствием в ней плескался еще 4 года. Проблема тут еще и в том, что когда игнорируемое «рассосалось» — ты обращаешь на это внимание и считаешь что твоя стратегия — эффективна. Но если проблема — осталась, то ты просто продолжаешь ее игнорировать и не учитываешь при анализе. Очень приятная лужа.

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

Иногда все действительно проходит «само». Но иногда — можно оказаться в огромной беспросветной заднице. Автор в ней бывал и крайне не рекомендует к посещению.
Поэтому я с улыбкой смотрю на компании, пытающиеся ввести культ сглаживания острых углов и позитивного мышления. Слишком уж хрупок карточный домик игнорирования проблем.

Кажется, здесь стоит прийти к выводу, что заклеивать мигающую красную лампочку «проблема» — крайне плохая стратегия, но…

Обезболивающие

Но это не так. И в этой луже я просидел еще 3 года.

Суть тут в чем: наш ментальный ушиб кокосом это не просто какая-то «субъективная фигня». Это следствие объективно происходящих процессов в объективно существующем мозгу. Его «боль» настолько же объективна, как боль обожженого пальца или пульпитного зуба. Мозг на физическом уровне атакует контрсигналами уже устоявшиеся связи и пытается уменьшить их силу, дополнительно врубая ковровые бомбардировки нейромедиаторами. (Могу объяснить в комментариях или отдельной статьей, почему я так думаю)

Когда у нас болит зуб — мы не спешим отказываться от анестезии. И не осуждаем других людей за то, что они попросили укол ультракаина перед удалением зубов. У нас не возникает желания сказать человеку, которому удаляют восьмерку — «Соберись тряпка! Это всего лишь зуб! От этого еще никто не умирал». (Хотя, наверное если бы половина людей в мире не испытывали боли при удалении зуба, а другая половина — просили бы обезболивающее, вторые очень быстро прослыли бы «тряпками, наркоманами, неспособными ни с чем справиться что без своих антидепрессантов обезболивающих».)

Когда нам фигово — мы действительно мыслим по другому. Это не самое подходящеее состояние мозга для построения цепочек сложнее, чем «трясти пальму->кокос упал->больно».

Любопытно то, что этот процесс может завести нас в цикл:
Мозг сфокусировлся на неприятном ощущении. Из-за этого мы забываем про то, что мозг во время неприятностей не работает в режиме «долговременного планирования». Вследствие этого в него не приходит мысль, что нужно успокоиться и вернуться в «режим планирования». Вместо этого мозг выбирает стратегию, которая приводит к новой порции неприятных ощущений. Мозг фокусируется на неприятном ощущении и еще дальше отходит от нормального режима работы.
(Потом объясню, почему так много вещей связанных с мозгом, имеют циклические и рекурсивные шаблоны).

Итого, игнорировать поступающую информацию — плохая стратегия, потому что это может привести нас к ошибке. Не игнорировать — тоже плохо, потому что болящий от кокосов мозг очень плохо соображает, и это приводит нас к ошибке. Безвыходная ситуация? Ну не совсем…

Компенсация воздействий

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

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

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

Где находится этот баланс? Знаете, если бы я был философом, я бы сейчас начал говорить, что-то многозначительное, умно звучащее и абсолютно бесполезное, вроде: «Каждый из нас — уникален, и каждый должен найти свой путь к равновесию… бла-бла-бла». Обычно всю пургу подобного рода следует переводить так: «Я не знаю». Но, поскольку я не философ, меня не устраивает такая концовка. У меня есть ответ и на это.

Как исправить?

Fail Fast.
Если мы знаем, что ошибки следуют из архитектуры и будут случаться, лучшее что мы можем сделать — определить их как можно раньше и не дать им стать ОШИБКАМИ. Чем дольше ошибка остается необнаруженной, тем больше последствий она имеет, как за пределами мозга так и внутри него.

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

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

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

Для этого существует эта статья.

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

  1. Затухание и укрепление связей — делают так, что свежая информация более доступна.
  2. Корреляция определяется как причинность — из-за этого возникают «пробелы» в моделях.
  3. Ложное понимание — из-за него мы не можем найти возникший пробел.
  4. Игнорирование — искажает воспринимаемую информацию. В теории этот механизм должен фильтровать мешающие факторы, на практике — можно увлечься и отфильтровать что-то полезное для решения задачи.

Четыре фактора, комбинация которых порождает почти все известные когнитивные искажения. А 4 причины запоминаются намного легче, чем 42 следствия.

Вот оставшийся список:

Есть ли в мозгах баги?

Мозг — удивительная вещь. Пока что мы не создали механизм, способный решать те же задачи что и он. Можно ли считать перечисленное ошибками архитектуры? Изъянами?
Я бы не был так категоричен. То, что мозг иногда не подходит для решения свалившейся на него задачи не говорит о том, что он чем-то плох. Я не буду стоит судить об эффективности микроскопа, по тому, как он забивает гвозди.

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

Скорее всего в этой статье есть ошибки, нюансы которые я упустил и места где я перемудрил с объяснением. Если вы заметили их — напишите пожалуйста.

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

Да, это разрушит 2 года моей работы и ударит по мне сильнее любого кокоса. Но это та цена, которую я плачу за возможность стать лучше. И пока что, я доволен обменным курсом.

That which can be destroyed by the truth should be. ― P.C. Hodgell, Seeker’s Mask

PS
Если вы что-то не поняли, или наоборот, вы бы хотели услышать более «техническое/математематическое» объяснение какого-то момента — будет здорово увидеть ваш комментарий. Я с удовольствием над ним подумаю и отвечу.
Если то, что я описывал расходится с вашими наблюдениями, или наоборот ваш опыт согласуется с моими выводами — я тоже с радостью послушаю такой фидбек.
Ведь Хабр — то место, где комментарии не менее интересны, чем сама статья.

ссылка на оригинал статьи https://habr.com/ru/post/494232/

Unity3D: Автоматический агрегатор скриптов-менеджеров

Вступление

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

Задачи

Я пришел к выводу, что забивать своими собственными ручками менеджеры в класс-агрегатор каждый раз — это дико неудобно. При создании нового менеджера придется открывать класс-агрегатор и вносить изменения. При достаточном количестве опыта можно такие нудные процессы автоматизировать. Таким образом поставились задачи: автоматическое создание синглтонов и их автоматический сборщик.

Класс-Singleton

using UnityEngine; public class Singleton<T>: MonoBehaviour where T: MonoBehaviour { 	public static T instance { get; private set; }  	public void Awake() 	{ 		if (instance == null) 		{ 			instance = GetComponent<T>(); 			ManagersAregator.addManager(instance); 		} 		else 		{ 			Debug.Log($"<color=red>Удаление дубликата синглтона {typeof(T).ToString()}</color>"); 			Destroy(gameObject); 		} 	}  	public void OnDestroy() 	{ 		ManagersAregator.removeManager<T>(); 	} } 

В классической реализации синглтона в Unity используется статическая переменная instance. В методе Awake() производится проверка, определен ли instance. Если нет, то получаем ссылку на экземпляр класса с помощью ключевого слова this. Но т.к. в конкретной реализации используется «шаблонная» переменная класса Т, использовать this не получилось. Но мы с легкостью можем получить компонент Т с объекта, на котором висит скрипт. Если же instance определен, то его необходимо уничтожить. Таким образом объект всегда будет на сцене в единственном экземпляре.

В методе Awake() в класс-агрегатор добавляется новый элемент, а в методе OnDestroy() элемент удаляется из класса-агрегатора.

Создание синглтона класса MyClass происходит так:

public class MyClass: Singleton<MyClass> 

Если надо использовать метод Awake() в классе MyClass, то надо воспользоваться ключевым словом base (подробнее о base и наследовании):

new void Awake() 	{ 		base.Awake(); //Вызывается метод Awake() класса-родителя 		//необходимый код 	} 

Класс-агрегатор

using System.Collections.Generic; using UnityEngine;  public static class ManagersAregator { 	static Dictionary<string, MonoBehaviour> Managers = new Dictionary<string, MonoBehaviour>();  	public static void addManager<T>(T newManager) 	{ 		string keyWord = typeof(T).ToString();  		if(Managers.ContainsKey(keyWord)) 		{ 			Debug.Log($"[ManagersAregator] Менеджер -{newManager}- с ключом -{keyWord}- уже существует"); 		} 		else 		{ 			Managers.Add(keyWord, newManager as MonoBehaviour); 			Debug.Log($"<color=green>[ManagersAregator] Добавлен новый менеджер -{newManager}- с ключом -{keyWord}-</color>"); 		} 	}  	public static T getManager<T>(string callback) where T: Singleton<T> 	{ 		string keyWord = typeof(T).ToString();  		if(Managers.ContainsKey(keyWord)) 		{ 			Debug.Log($"<color=yellow>[{callback}] Получение менеджера -{keyWord}-</color>");  			MonoBehaviour mbTemp = null; 			T manager = null;  			if(Managers.TryGetValue(keyWord, out mbTemp)) 			{ 				manager = (T)mbTemp; 				Debug.Log($"<color=green>[{callback}] Менеджер -{manager}- получен</color>"); 			} 			else 			{ 				Debug.Log($"<color=red>[{callback}] Ошибка получения менеджера -{keyWord}-</color>"); 			}  			return manager; 		}  		Debug.Log($"<color=red>[ManagersAregator] Менеджер с ключом -{keyWord}- отсутствует в словаре.</color>"); 		return null; 	}  	public static void removeManager<T>() 	{ 		string keyWord = typeof(T).ToString();  		if(Managers.ContainsKey(keyWord)) 		{ 			Managers.Remove(keyWord); 			Debug.Log($"[ManagersAregator] Менеджер с ключом -{keyWord}- удален из словаря"); 		} 		else 		{ 			Debug.Log($"[ManagersAregator] Менеджер с ключом -{keyWord}- отсутствует в словаре."); 		} 	} } 

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

Все скрипты-менеджеры (синглтоны) хранятся в словаре Managers. Ключом для каждого менеджера является имя класса этого менеджера. Возможно, новички в программировании зададут вопрос: «Ба, а что это словарь хранит MonoBehaviour, а все классы наследуются от Singleton?». Это хороший вопрос, ответ на который и является ключом к реализации автоматического агрегатора менеджеров любых классов.

В программировании существует понятие upcasting — преобразование типа к базовому классу. Благодаря тому, что все классы в Unity наследуются от MonoBehaviour, их можно апкастить к MonoBehabiour. Поэтому словарь Managers содержит только объекты класса MonoBehaviour.

Рассмотрим методы класса-агрегатора:

void addManager<T>(T newManager)

Этот метод вызывается в методе Awake() класса Singleton. Аргументом является статическая переменная класса instance. Далее создается ключ по имени класса, которому принадлежит instance, и менеджер добавляется в словарь.

T getManager<T>(string callback) where T: Singleton<T>

Функция принимает аргументом строку с именем класса, откуда вызывается метод. Это сделано исключительно для удобного дебага (в консоли отображается класс, откуда вызывается метод). Пример использования этого метода в класса AnotherMyClass:

public class AnotherMyClass: MonoBehaviour 	void Start() 	{ 		string cb = GetType().ToString(); //Получение имени класса в качестве строки 		MyClass MC = ManagersAregator.getManager<MyClass >(cb); 	} 

В консоли будет висеть сообщение: "Ху**я, переделывай [AnotherMyClass] Менеджер -MyClass- получен".

void removeManager<T>()

Удаляет из словаря менеджер типа Т, если он содержится в словаре.

Итоги

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

Надеюсь, эта статья была для вас полезной и вы узнали что-то полезное для себя!

ссылка на оригинал статьи https://habr.com/ru/post/494930/

С днём бэкапа! Не забывайте о нём

Пока по планете гуляет версия 2020 года, заражённая вирусом, не стоит забывать, что и данные, и бизнес, и коммерческая информация тоже под угрозой. Неизвестно, что произойдёт завтра: взлом, угон информации, кража, отказ хостера в обслуживании. Мы немного устали от тяжёлой информации, думаем, вы тоже. Поэтому сегодня — открытка об основных правилах работы с бэкапами в самой лёгкой форме.


Угрозы разные и злые,
Придут оттуда, где не ждёшь.
Блюди ты правила простые
И не впадай при краше в дрожь.


Бэкапь всегда, бэкапь везде
От данных до конфигов.
Угрозам, взломам и беде
Тогда покажешь фигу.

Одни лишь данные бэкапить — 
Почти что преступление.
Чтобы прод не профакапить, 
Копируй окружение. 

О чём речь?

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


Обновляй бэкапы данных
Регулярно и везде.
Если нет их актуальных
Непременно быть беде.

О чём речь?

Все бэкапы должны поддерживаться в актуальном состоянии — это должны быть либо обновления по расписанию, либо ручные обновления сразу после внесения изменений в системы и данные. Обязательно храните дату создания резервной копии, чтобы знать, что именно у вас есть для возможного восстановления.


Проверять восстановление 
Данных из бэкапа
Не привыкло поколение — 
Это грешновато.

О чём речь?

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


По расписанию бэкапь
И не забудь проверить.
Машина тоже может встать,
Не нужно слепо верить.

Не доверяй бэкап коллеге,
Не доверяй его скриптам.
Верна одна лишь из стратегий:
Бэкапы есть? Проверь их сам!

О чём речь?

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


Делай реплики БД
Серьёзно и синхронно.
Это фору даст тебе
В случае урона.

Делай дампы SQL — 
Перебдеть не бойся.
Если что они тебе
Уменьшат беспокойство.

О чём речь?

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


Если в облако загружен 
Весь коммерческий массив,
То бэкап как воздух нужен, — 
В облаках бывает слив.

О чём речь?

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


Снятый с базы каждый дамп
Не откладывай устало.
В жизни может статься так:
Дампы есть, а данных мало.

Дампы в базу ты залей,
Прочекай актуальность.
Нет иных других путей,
Прими совет как данность.

О чём речь?

Всё просто: сняли дамп, проверили его, залили, посмотрели, как получается и насколько актуальные данные подгружаются. Хранить дампы без проверки чревато как минимум устареванием данных, как максимум — их полной потерей.


Скорость доступа к бэкапам 
Познаётся в форс-мажоре.
Так не будь головотяпом — 
Протестируй априори.

О чём речь?

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


Во избежание факапов
Помни про три-два-один:
Сделай ровно три бэкапа,
На два носителя закинь.
Одну копию бери
И вне офиса храни.

О чём речь?

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


Если прод на хостинг А
Разместил культурно,
Не тащи бэкап туда,
Это не секьюрно.

Потащи на хостинг Б,
Застрахуйся, друже,
Избежишь вагон проблем
И кидков похуже.

О чём речь?

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


Короче…

Я не поэт, но я скажу стихами:
Бэкапы есть — не будете лохами.


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

ссылка на оригинал статьи https://habr.com/ru/company/regionsoft/blog/494938/