Предложите другую модель монетизации.
А то есть мнение что блокировщики убили интересный контент на корню.
https://habr.com/post/427047/---------- Добавлено 20.10.2018 в 13:02 ----------
Это сокращает число сайтов с интересным бесплатным контентом.
Речь об абузах. Когда хостер в черных списках.
Простая там настройка ISPManager или не простая - это ничем вам не поможет.
Не-а. Для них упомянутые технологии - вообще сродни космическим.
Я тут недавно объяснял как отправлять почту разработчику сайтов с, вдумайтесь, с 20-ли летним опытом, который до сих пор, в наше время, когда почтовые сервисы банят по малейшему подозрению - использовал штатный функционал PHP, когда отправка идет с почтового сервера, находящегося там же где и веб-сайт.
Ему так видите ли проще.
У него был разрыв шаблона - когда наконец-то его через пять раз на шестой доходящая почта, таки начала нормально работать.
И это 20 лет опыта.
Что же ожидать о тех, кто только вчера научился Windows ставить, а сегодня уже того - "веб-разработчик профессиональный"?
То, что лучше знает он и вы - на чем порешаете.
Если не будет динамики - то вам вообще фреймворк не нужен в браузере.
А крайне полезен будет ES6 и более свежий, в котором уже запилили основной функционал из jQuery.
Разумеется, нужна будет транспиляция для того, чтобы старые браузеры поддерживали. А большего не особо и не нужно, никаких фреймворков.
Для транспиляции рекомендую Rollup + Babel, это будет проще и быстрее работать, чем более старые, но более известные комбинации с Webpack, Gulp, Grunt. А заодно и код вычищаться неиспользуемый будет.
Если веб-морда сайта динамическая - то сейчас активно хвалят, в том числе и за простоту и функциональность Vue.JS.
Если сайт с очень сложным веб-интерфейсом - то уже имеет смысл мощь Angular.
В любом случае, если речь касается современных инструментов - то дело будет не только в фреймворке.
Еще и современная версия JavaScript с транспиляцией или TypeScript или Dart. Без них, на старой версии JavaScript, современные фреймворки не работают или вообще или работают ограничено.---------- Добавлено 19.10.2018 в 19:40 ----------
Во первых, jQuery не фреймворк. А библиотека.
Во вторых, самый часто употребимый функционал jQuery уже несколько лет как перекочевал в современные версии Javascript (начиная с ES6/ES2015) и для проекта, начинаемого "с нуля" нет никакого смысла в jQuery. Тут jQuery уже сделал свое дело, на нем были отточен тот функционал, что в конечном итоге вошел в сам язык программирования.
Необходимость jQuery на сегодня еще есть:
---------- Добавлено 19.10.2018 в 19:43 ----------
Ну тут зависит от того, что за планы вы ставите перед собой.
Скажем если рассматриваете как пример Megaplan,
то посмотрите и на опыт Wrike.
Их опыт - это создание полноценнейшего приложения, исполняемого в браузере.
Они выбрали AngularDart - по их мнению для подобного сложного функционала это то, что надо.---------- Добавлено 19.10.2018 в 19:44 ----------
Это касается только простых проектов.
Для сложных - никакие тонны документации по другому коду вам не помогут.
Когда ваш собственный недокументированный код станет достаточно велик...---------- Добавлено 19.10.2018 в 19:46 ----------
Для любого сколько нибудь сложного проекта - разработчику придется вникать и вникать в тонны уже написанного.
Это нормально.
Это его типичная работа.---------- Добавлено 19.10.2018 в 19:53 ----------
Это не совсем так.
Года три живет версия.
Но за три года вы напишите тонну своего кода, из-за которой фреймворк будет с трудом виден. И основные проблему будут уже у кода вашего, а не у кода фреймворка.
Если вы достаточно компетентны, чтобы работать с такими тоннами кода, то и сами должны понимать, что вам придется как-то это все структуировать, причем сразу.
Вы или придумаете свою структуру, по сути, свой фреймворк - или воспользуйтесь готовым.
В любом случае - выбор инструмента это дело самого разработчика. Или старшего разработчика в группе разработчиков.---------- Добавлено 19.10.2018 в 19:56 ----------
Люблю я такие примеры: "Как у Гитхаба, как у Гугля и т.п."
Но больше всего люблю, когда такие аргументы приводят, не обращая внимания на то, что исполнять проект будут специалисты, чья квалификация страшно далека от квалификации разработчиков Гитхаба и пр.
"То, что хорошо Юпитеру, то противопоказано быку."
Шибко древняя латинская поговорка.---------- Добавлено 19.10.2018 в 19:59 ----------
Что именно "проще и быстрее" - зависит от конкретных навыков конкретного разработчика.
Выбор jQuery в конце 2018 года для нового проекта - довольно странный выбор.
Ибо часто используемый функционал jQuery уже года 3 как въехал в сам язык Javascript (начиная с ES6/ES2015; поддержка старых систем делается автоматически - через трансиляцию).
Но то, что выделена стадия прототипирования и на ее основе будет принято решение - это правильно.
Неправильным будет если будет желание сэкономить и сделать основную версию на основе кода прототипа. Так как прототипирование делают вовсе без расчета упрощения поддержки в будущем, а как бы совсем наоборот - тяп-ляп, лишь бы работало.
JS/CSS - просто приписываете формальный параметр в строчку с URL
"https://example.com/js/scriptname.js?v=101"
То, что после "?" - никак не на что не влияет, кроме кэша браузера.
Если html/картинки - то простой etag
Если ресурс каждый раз обновляется, то в заголовках http просто отключаете кэширование для этого ресурса.
Нет.
Для массовых рассылок я просто использую внешний сервер, специализирующийся на рассылках.
Для разовых писем - обычный почтовый ящик mail.ru/gmail.com и т.п., к которому подключаюсь через SMTP/POP3
Ситуация, когда вам нужен ваш личный почтовый сервер при этом вы пользуетесь треш-хостерами - не типичная. Точнее типичная - вы спамер. Но так вам и надо.
Хотите дешевле? А потом жалуются, что хостер говно...
Это не shared, это VDS на котором живет куча проектов.
В спаме затерялось письмо. Или вообще его получил человек не знающий что такое API - и в корзину сразу.
А если по старинке - просто позвонить?
Ну если для вас 4000 рублей за полгода - это "дорогой хостинг", тогда я не знаю как вообще хостеры выживают.
Вам везет - вы никому не нужны и случайно не были словлены.
Подобный пароль - уже перебор.
Проблема при прямом руте - совсем другая. Вовсе не в подборе пароля.
На первоначальном этапе установки соединения (а наверняка вы просто подтверждаете YES, когда вас SSH предупреждает о том, что сервер какой-то незнакомый) - ваше SSH-соединение может быть перехвачено или проксировано.
Таким образом первый пароль вы, гипотетически, можете ввести на чужом сервере, а не на своем.
Если этот пароль - пароль root, то все грустно.
К длине пароля и/или его сложности - это не имеет отношения.
