Это так, только если у вас апач напрямую торчит наружу
Видимо, я непонятно выразил мысль. Второе предложение не вытекает из первого, они независимы.
С mod_php большая проблема — использование оперативной памяти.
На просторах интернета не нашел единого рецепта по установке и настройке такого, довольно нестандартного сервера
Хм. Вообще это очень распространенная стандартная двухуровневая конфигурация nginx+apache. Интересно — а зачем вам Apache?
В конфиге nginx — хедеры для безопасности и сразу после них строчка resolver 8.8.8.8; дырка в безопасности оставленная собственными руками. Из документации: для предотвращения DNS-спуфинга рекомендуется использовать DNS-серверы в защищённой доверенной локальной сети.
Если популярные поисковики при запросе о технологии выдают статьи 2010-2012 годов, не находится нормальная документация, а stackoverflow также не многословен, то технологию можно считать устаревшей
Забыли добавить — «как мне кажется». Ибо я могу предложить другую трактовку. Технология настолько проста и хорошо документирована что у Apache, что у nginx — что там и обсуждать то нечего.
Вначале сказать, что решение неправильное, плохое, потом прикрыться словами, что в дискуссии не участвуете. Потом все-таки вступить в дискуссию. Потом сказать человеку, что он не прав в терминологии. После ответа вместо контр-доводов сказать «Откланиваюсь, читайте книги. а не википедию». Всё понятно.
Забыли еще несколько пунктов. Честно пытаться разобраться в вашей терминологической путанице и пытаться понять, какую же задачу вы решали, а после того, как это все-таки мне удалось, често признаться, что был неправ и ваше решение неплохое, с учетом всех нюансов.
Поэтому еще совет. Читайте собеседника внимательно.
Ох, участвовать в дискуссии, заранее зная, чем она закончится..., но было любопытно скорее с точки зрения психологии.
Вот я пишу:
стараюсь не участвовать в религиозных спорах… Могу сказать, что технология SSI известна больше 20 лет, но наверняка нарвусь на обвинение в «подходе динозавра».
Ну и вы:
Но SSI к этому не относится. Эта технология устарела и никто её не пользуется.
(С грустью) Опять угадал.
Но все-же хочу дать вам несколько советов
Про файловый сервер NetWare что-нибудь слышали?
как человек, который писал NLM для Novell Netware (намек на возраст).
Но SSI к этому не относится. Эта технология устарела и никто её не пользуется.
Если вы не уверены в своем утверждении, не выдавайте свои домыслы за непреложную истину. Человек, узнавший об SSI пару дней назад, мог бы добавить «как мне кажется».
Если бы у меня стоял выбор какую технологию выбрать, то остановился на старом добром PHP, который пока что не устарел.
Никогда не говорите так на собеседовании. SSI и PHP — это даже разные предметные области.
Откланиваюсь, читайте книги. а не википедию, всяческих вам удач в дальнейшем.
Но это уже чисто терминалогический спор: статический сайт определяется со стороны клиента или сервера
Коллега, поясните, пожалуйста, вашу мысль — «статический сайт со стороны клиента»?
Вам действительно надо привести в порядок терминологию, хотя бы для того, чтобы ваши читатели вас правильно понимали.
:) Ну а потом, после потом… Нет уж, давайте я не буду тратить свое и ваше время, а просто соглашусь, что был неправ, и ваше решение совсем неплохое. если учитывать все нюансы.
подскажите, пожалуйста, мне недалекому, который основ не знает, как с помощью SSI сгенерировать статические html файлы
SSI не генерирует статические html файлы, а позволяет делать вставки в статические html файлы. Например, создаете статические header.html и footer.html. Потом можете создавать сколько угодно статических html файлов примерно следующего содержания:
Server Side Includes — зачем вы предлагаете инструмент динамического сайта для статического сайта? Вы это серьезно? Нужна будет динамика
Дальнейшие обсуждения не имеют смысла. Динамического? Нет, серьезно? Т.е. вы на самом деле считаете. что статику нельзя подключать через SSI? Знаете, прежде чем следовать моде, неплохо бы с основами разобраться.
Как вы сами признали, оно не является оптимальным. Почти по всем параметрам — время на разработку, пара тысяч зависимостей (в курсе истории о том, что было, когда одна из зависимостей сломалась и пропала из репо?), дальнейшее сопровождение и т.д. и т.п. Иными словами — вы простейшую, можно сказать — тестовую задачу решали, создавая себе максимальные сложности.
Однако опять отмечу, что если вы все-таки решали другую задачу (самообучение), то задача решена хорошо.
К сожалению, сейчас повсеместная беда с постановкой задачи, как таковой. Люди путают цели со средствами их достижения.
И какое решение, на ваш взгляд, хорошее?
Понимаете, как штука… Думаю, что это риторический вопрос с вашей стороны, потому что во первых, в комментах уже писали как минимум о нескольких, во вторых, стараюсь не участвовать в религиозных спорах.
Ну как пример, вы пишите о подключаемых хедере и футере, что код шапки прописывать вручную в тысячах файлов — это ад…
Могу сказать, что технология SSI известна больше 20 лет, но наверняка нарвусь на обвинение в «подходе динозавра».
Вы сами себе противоречите… А то, что современный подход является оптимальным решением — я этого нигде не говорил.
Вроде нет противоречия. Поясню. Я исхожу от задачи, озвученной вами в статье. Задача решена, но плохо, хоть и современными методами.
Если бы ваша постановка задачи выглядела как-то так:
Задача (цель): Изучить современные технологии (webpack)
Способ решения: Собрать простой статический сайт с помощью webpack 4.
то можно было бы сказать, что задача решена хорошо.
Современный подход, к сожалению или к счастью, выглядит так
Вы ошибаетесь. Подход сам по себе не может быть «современным» или «олдовым». Любой подход определяется выбором правильного инструмента для реализации. Вы выбрали современный инструмент, но это вовсе не значит, что этот инструмент обеспечил правильный подход и правильное/оптимальное решение вашей задачи.
Хочу добавить к вашему списку еще одну книгу. Она не свежая, но большинство молодых программистов о ней не знают. По ней учились и зачитывали до дыр в 80-е, но, тем не менее, мне кажется, что она по прежнему актуальна.
Program Style, Design, Efficiency, Debugging, and Testing
автор — Dennie Van Tassel, написана в 1978 году
В переводе на русский Стиль, разработка, эффективность, отладка и испытание программ
было два издания 1981 и 1985
это непредсказуемый с точки зрения состояния объект с непредсказуемым количеством связей
Поправлю. Синглтон — это все-таки не объект, а шаблон проектирования. И суть его в общем случае не в гарантии единственности экземляра своего класса, а в гарантии единственности экземляра некоторого класса. «Свой класс» — это частный случай, и, как правило, именно такое использование синглтона вызывает непредсказуемость.
А поглядите, например, на совместное использование шаблонов синглтон + фабрика. Тут даже с единой ответственностью все в порядке.
В общем синглтон обманчиво прост, подводные камни есть, но Suvitruf прав — готовить его можно.
Мое решение в виде модуля подходит для тех случаев, когда проблема с определением формата файла должна решаться внутри другого продукта. Как вы понимаете, в таком случае внешние утилиты не подходят.
Что-то я совсем запутался. Ваше решение чего? Какую проблему вы решали?
Если вы решали проблему определения формата файлов на карте памяти и их переименования (как описали в заголовке статьи), то можно сказать, что вы написали свой велосипед. Мне потребовалось менее минуты, чтобы написать однострочник на bash+file+awk+sed для решения этой проблемы. В windows я слаб, но судя по сообщению коллеги WebConn и там она решается не сложнее.
Ну а если вы решали проблему «попрактиковаться в программировании на Python» и нашли под нее задачу, то все хорошо и понятно. Только тогда ваша статья приобетает совсем другой смысл и обсуждение как мне кажется шло бы в другом ключе, во всяком случае отсылки к готовым решениям были бы «не в тему».
ОРМ — это решение проблемы связи объектов на рсубд и обратно.
Точная, короткая, но ёмкая формулировка.
К сожалению многие (включая автора данной статьи) видят в ОРМ просто новый уровень абстракции для замены синтаксиса SQL запросов.
Мы прошли долгий путь, с тех дней когда мы в ручную писали SQL запросы в наших веб приложения. Инструменты, такие как Laravel’ий Eloquent ORM позволяют нам работать с базой данных на более высоком уровне, освобождают нас от деталей более низкого уровня — таких как синтаксис запросов и безопасность.
В реальной жизни схемы баз данных — на полстены. Или на всю стену. Как повезёт. И запросы к ним — на сотни строк SQL-кода. Интересно, как в таких бесчеловечных условиях будет работать Eloquent ORM?
А никак. Кмк ОРМ предназначен для решения совсем другого класса задач.
Для тех кто считает статью плохой и ставит минусы: пишите пожалуйста в комментарии почему вы так решили.
Хотя минусов я не ставил да и не могу я этого делать, но попробую сформулировать причину, почему мне не понравилась статья.
Проблемы, описанные вами, уже лет 10 как довольно будничные и не представляют какой-либо теоретической ценности. Профессионалы решают их «по щелчку» и без всякого интереса — ибо набили оскомину.
Мы создали новый запрос в техподдержку, с просьбой уточнить, в каких именно файлах был обнаружен вредоносный скрипт, для того, что бы иметь хоть какое то представление, что искать.
Вы даже не представляли, что искать? Это многое объясняет. Но мне искренне жаль техподдержку. Вы ведь прочитали предыдущую переписку, об этом было написано в первом письме от них.
А вообще, это предложение как раз и характеризует мое отношение к вашей статье.
Вы подаете материал, как свою победу в маленькой войне, а на самом деле решили курсовую работу. Победа — это хорошо, но мне странно наблюдать за студентом, решившим задачу, уничижительно отзывающегося о других студентах, которые с задачей не справились.
С mod_php большая проблема — использование оперативной памяти.
Nginx configurations for most popular CMS/CMF/Frameworks based on PHP
В конфиге nginx — хедеры для безопасности и сразу после них строчка resolver 8.8.8.8; дырка в безопасности оставленная собственными руками. Из документации: для предотвращения DNS-спуфинга рекомендуется использовать DNS-серверы в защищённой доверенной локальной сети.
Забыли еще несколько пунктов. Честно пытаться разобраться в вашей терминологической путанице и пытаться понять, какую же задачу вы решали, а после того, как это все-таки мне удалось, често признаться, что был неправ и ваше решение неплохое, с учетом всех нюансов.
Поэтому еще совет. Читайте собеседника внимательно.
Вот я пишу:Ну и вы:
(С грустью) Опять угадал.
Но все-же хочу дать вам несколько советов как человек, который писал NLM для Novell Netware (намек на возраст).
Если вы не уверены в своем утверждении, не выдавайте свои домыслы за непреложную истину. Человек, узнавший об SSI пару дней назад, мог бы добавить «как мне кажется».
Никогда не говорите так на собеседовании. SSI и PHP — это даже разные предметные области.
Откланиваюсь, читайте книги. а не википедию, всяческих вам удач в дальнейшем.
Вам действительно надо привести в порядок терминологию, хотя бы для того, чтобы ваши читатели вас правильно понимали.
Однако опять отмечу, что если вы все-таки решали другую задачу (самообучение), то задача решена хорошо.
К сожалению, сейчас повсеместная беда с постановкой задачи, как таковой. Люди путают цели со средствами их достижения.
Понимаете, как штука… Думаю, что это риторический вопрос с вашей стороны, потому что во первых, в комментах уже писали как минимум о нескольких, во вторых, стараюсь не участвовать в религиозных спорах.
Ну как пример, вы пишите о подключаемых хедере и футере, что код шапки прописывать вручную в тысячах файлов — это ад…
Могу сказать, что технология SSI известна больше 20 лет, но наверняка нарвусь на обвинение в «подходе динозавра».
Если бы ваша постановка задачи выглядела как-то так:
Задача (цель): Изучить современные технологии (webpack)
Способ решения: Собрать простой статический сайт с помощью webpack 4.
то можно было бы сказать, что задача решена хорошо.
Program Style, Design, Efficiency, Debugging, and Testing
автор — Dennie Van Tassel, написана в 1978 году
В переводе на русский
Стиль, разработка, эффективность, отладка и испытание программ
было два издания 1981 и 1985
Чтобы понять дух этой книги, поглядите цитатник из нее.
А поглядите, например, на совместное использование шаблонов синглтон + фабрика. Тут даже с единой ответственностью все в порядке.
В общем синглтон обманчиво прост, подводные камни есть, но Suvitruf прав — готовить его можно.
Если вы решали проблему определения формата файлов на карте памяти и их переименования (как описали в заголовке статьи), то можно сказать, что вы написали свой велосипед. Мне потребовалось менее минуты, чтобы написать однострочник на bash+file+awk+sed для решения этой проблемы. В windows я слаб, но судя по сообщению коллеги WebConn и там она решается не сложнее.
Ну а если вы решали проблему «попрактиковаться в программировании на Python» и нашли под нее задачу, то все хорошо и понятно. Только тогда ваша статья приобетает совсем другой смысл и обсуждение как мне кажется шло бы в другом ключе, во всяком случае отсылки к готовым решениям были бы «не в тему».
К сожалению многие (включая автора данной статьи) видят в ОРМ просто новый уровень абстракции для замены синтаксиса SQL запросов.
Поэтому понятно непонимание maslyaev
А никак. Кмк ОРМ предназначен для решения совсем другого класса задач.
Хотя минусов я не ставил да и не могу я этого делать, но попробую сформулировать причину, почему мне не понравилась статья.
Проблемы, описанные вами, уже лет 10 как довольно будничные и не представляют какой-либо теоретической ценности. Профессионалы решают их «по щелчку» и без всякого интереса — ибо набили оскомину.
Вы даже не представляли, что искать? Это многое объясняет. Но мне искренне жаль техподдержку. Вы ведь прочитали предыдущую переписку, об этом было написано в первом письме от них.
А вообще, это предложение как раз и характеризует мое отношение к вашей статье.
Вы подаете материал, как свою победу в маленькой войне, а на самом деле решили курсовую работу. Победа — это хорошо, но мне странно наблюдать за студентом, решившим задачу, уничижительно отзывающегося о других студентах, которые с задачей не справились.