Finesse

https://github.com/danakt/russian-words
Использовал данную базу для написания инструмента для проверки орфографии. В файле скомбинировано несколько найденных мной баз, содержит русские слова во всех формах и русские имена. Так же есть файл со списком русских фамилий.

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

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

Больше спама нет.

hack, trick

НЕЛЬЗЯ! И вполне правильно, если я закрыл приложение, я должен быть уверен, что оно не будет работать от слова совсем, иначе это уже какое-то Ведро выходит.

BackgroundFetching - это только про свёрнутое приложение.

Раньше считал что самый лучший шаблонизатор это PHP и жутко спорил со всеми кто не был с этим согласен, после того как пришлось попользовать Twig, кардинально переменил свою позицию. Очень удобный, конструкции твига намного короче аналогов на php, есть поддержка в IDE, например PhpStorm. В плане производительности, практически никакого оверхеда, они компилируются в php код при первом запуске.

cd /
du -sh *
как то-то так ?
Ну или так
du -sh * | grep G
( только гигабайты)

Попробовал twig и в новых проектах отказался от «нативного шаблонизатора», хотя всегда был его горячим сторонником. Основная причина — в twig по умолчанию включено экранирование вывода и {{user.name}} куда короче (и понятней верстальщику), чем <?php echo htmlspecialchars($user->name, ENT_QUOTES, 'UTF-8') ?>. Плюс для удобного использования хелперов и переменных (хотя бы замены htmlspecialchars($user.name, ENT_QUOTES, 'UTF-8') на escape($user-name), а в идеале просто $user->name), требует вторжения в глобальную область видимости, что может привести к трудно улавливаемым глюкам.

Телеграм официально представил сервис, через который все это можно сделать. Вот инструкция по настройке репоста: https://antonov.work/73-ifttt-avtomaticheskiy-repo...

showinfo=0, например:

https://www.youtube.com/embed/ffiJNSy8CBA?&theme=dark&autohide=2&showinfo=0

Вы IT специалист? Какая нафиг трудовая? Никто не будет в неё смотреть при вынесении решения брать вас на работу или нет, смотрят только на ваши знания

Подтверждаю, Twig хорош. Если вы используете Laravel, но лень прикручивать Twig, тогда Blade.

Один из омонимичных доменов:

.am — национальный домен Республики Армения, созвучен с диапазоном радиостанций AM или как зона AMerica.
.cd — национальный домен Демократической республики Конго (иначе — Заира), совпадает с сокращением для компакт-диска.
.dj — национальный домен Джибути, совпадает с сокращением «диджей».
.fm — национальный домен Федеративных Штатов Микронезии, созвучен с диапазоном радиостанций FM. Пример: last.fm.
.im — национальный домен Острова Мэн. Совпадает с сокращением Instant Messaging («мгновенные сообщения»).
.io — национальный домен Британских территорий в Индийском океане. Совпадает с сокращением Input Output («ввод/вывод»).
.is — национальный домен Исландии. Совпадает со словом is, формой третьего лица единственного числа английского глагола to be. Пример: who.is
.it — национальный домен Италии. Совпадает с сокращением IT (информационные технологии), а также с английским местоимением it («это»). Пример: ok.undo.it
.md — национальный домен Молдавии. Совпадает с сокращением аудионосителя MiniDisc и с сокращением Must Die. Также совпадает с сокращением от англ. medical doctor, используемым повсеместно в англоязычных странах. Например, известный американский сериал «Доктор Хаус» в оригинале называется House, MD.
.me — национальный домен Черногории. Совпадает с местоимением «меня», «мне» в английском и других европейских языках.
.net — общий домен верхнего уровня, совпадает с русским словом «нет», из-за чего обрёл в России (и не только) дополнительную популярность. Часто используется с доменными именами в виде транслитерированных русских слов. Примеры: mozga.net, lishnih.net.
.nu — национальный домен острова Ниуэ, созвучно со словом ню.
.tm — национальный домен Туркменистана, совпадает с аббревиатурой «™» (англ. trade mark — торговая марка).
.tv — национальный домен Тувалу, совпадает с аббревиатурой «Телевидение».
.ws — национальный домен Западного Самоа, совпадает с аббревиатурой Web Site.
.in — национальный домен Индии, с английского языка переводится как предлог «в».
.li — национальный домен Лихтенштейна. Совпадает с окончанием глаголов и имён существительных в русском языке. Используется с доменными именами в виде транслитерированных русских слов. Примеры: zadolba.li, zastuka.li, vaf.li, gus.li, yas.li.
.pro - общий домен верхнего уровня для профессионалов в своей области.

Защита простая (всякие csrf итд не упоминаю)

1) перед ставкой в базу экранировать данные от SQL инъекций
2) перед выводом в браузер экранировать данные от XSS атак

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

Например, в Symfony2/3 есть такая штука как "DataTransformers", которая преобразует данные при сохранении/извлечении по заданной формуле. В Laravel 5.x - есть "Мутаторы", которые произволят аналогичные манипуляции с полями модели. Так же в зависимости от фреймворка, могут быть разнообразные фильтры, преобразователи и так далее.

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

Но, давайте рассуждать логически. Вам когда-нибудь будет нужен текст 100% оригинал? То есть, такой текст, который бы сохранил все теги, которые ввёл пользователь, все пробелы (в том числе и лишние), регистр этих тегов и пр. подробности/особенности того, что пользователь ввёл?

Если да, но эти данные Вам будут нужны редко, для какой-то статистики например - то сохраняйте их в каком-то отдельном поле в БД, типа "user_text_original".

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

И, самый вероятный вариант:
Если же, данные в их оригинальном виде Вам не нужны в 99% случаев, а нужны Вам уже отфильтрованные данные, с которых вычищены все лишние HTML-теги например, то возникает резонный вопрос: зачем постоянно гонять фильтры туда-суда, сохраняйте сразу отфильтрованные данные в БД, в соответствии с возможностями и механизмами Вашего фреймворка (как я уже писал выше, это могут быть DataTransformer'ы, Мутаторы и т.д.). Так как Вы удаляете из данных теги - их объём сокращается (это плюс), и так как Вы дёргаете фильтр всего 1 раз, сокращается нагрузка на систему (это так же плюс). Но такой расклад будет работать только в том случае, если сохраненные данные будут получаться чаще, чем сохраняться. То, например, если Вы выводите на страницу комментарии, то каждая независимая единица комментария, должна быть показана хотя бы 2 раза. То есть, если у Вас есть 1000 комментариев всего, то обработаться/отобразиться за всё время жизнедеятельности сайта, должно не менее 1000 комментариев, иначе фильтр будет убыточен с точки зрения производительности (такой вариант мало вероятен, но гипотетически возможен, что у Вас данные добавляются чаще, чем отображаются/обрабатываются хотя бы раз).

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

P.S. Я бы конечно мог расписать всё ещё более подробно, но и так много получилось...

В этом месте:

на представлении при вставке текста в HTML;

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

Если более детально: вот схема. (блоки "Подготовка выходных данных модуля" и "Подготовка выходных данных приложения")