Почти у всех представленных макетов есть проблема с расширяемостью меню. Если 3-5 пунктов навигации — полет нормальный, но добавляем еще 10 и получаем впихнутые в дизайн скроллы / либо подпункты, где конечный пользователь ногу сломает. Хотя все зависит от конечной задачи.
Касательно самого обзора, то имхо самый большой минус — это вердикт для всего макета по одной картинке. Возможно, проблема озвученная выше, грамотно обыграна на реальном сайте, но понять это по 1 картинке нельзя. Адаптивный дизайн — норма жизни, знает ли об этом автор N-макета? Для нас останется загадкой или интригой (кому как больше нравится).
Хорошее решение для архивации малого калибра, но помимо корпорации добра, рекомендую попробовать яндекс диск для подобных целей. Порог вхождения ниже, а гибкость настройки больше. Из объективных минусов — бесплатного сыра здесь только 10 ГБ,
Дружит с Ubuntu, Debian, Fedora, Red Hat, Centos. Существуют версии i386, x86, x64, x86_64. Консольную утилиту можно ставить из deb-файла, через apt-get (надо указать репозиторий) или RPM.
Настраивать можно через визард (yandex-disk setup) консольной утилиты или просто редактированием конфигурации. Может работать как в режиме постоянной синхронизации через демон, так и просто выполнить синхронизацию по команде (yandex-disk sync). Можно указывать что синхронизовать, либо что не трогать, разрешить/запретить перезапись и т.п.
Базовая настройка резервного копирования с момента коннекта по ssh займет минуты 2-3.
Еще умеет работать с webdav, что в сочетании с парой утилит позволяет создать кластер из дисков, объединенный в одно дисковое пространство. Но нюансов там не мало, так что это совсем другая история.
Не буду разводить на холиваров на тему апача в 2к16, лампа на локалке дело обычное, но действительно пугают следующие вещи:
— конфиг mod_rewrite;
— INSERT в БД по GET запросу;
— INSERT в БД без CSRF;
— определение причинно-следственной связи.
Школьнику/студенту еще простительно, но 5 лет разработки в вебе?
ps. Почитал комментарии. Товарищам, считающим, что ТС добавлял записи для счетчика просмотров — прошу прочитать первый абзац в статье чуточку внимательнее, где явно указано про форму комментариев. Хотя и с прямым взаимодействием (вставка/обновление) с БД при реализации счетчика просмотров я бы поспорил.
А откуда сервер узнаёт какие данные ещё запросит клиент? Ну вот на том же примере запроса страницы с картинками. Серверу нужно, во-первых, откуда-то знать какие ресурсы нужно отдавать с этой страницей, во-вторых, откуда-то знать какие ресурсы клиент уже загрузил, а какие — нет, чтобы не оказать медвежью услугу и не пулять данные, которые уже есть.
При отдаче страницы мы сами указываем какие данные попадают в категорию «загрузить сразу». Прописывается в заголовках, соответственно это можно делать как на статике, так и на уровне бэкенда.
Да, кстати, клиент их вполне мог закэшировать и они ему не нужны вообще — особенно это касается статики.
Вот тут попрошу поправить меня уважаемых знатоков, но как я понял, этот процесс мы отслеживаем самостоятельно.
Если клиент пришел на сайт первый раз — отдаем данные пачкой, получаем плюс в производительности.
Если мы знаем, что клиент получил данные и использует кэш, все ок — не отдаем preload.
Если мы «профилонили» и у клиента больше нет кэша, он запросит его сам. Но и здесь буст по сравнению с HTTP1, т.к. это будет сделано без открытия нового соединения *
* Если используются CDN-сервера или кросс-доменные соединения, то прироста в производительности не будет, т.к. в этом случае браузер будет открывать новые соединения.
Касательно самого обзора, то имхо самый большой минус — это вердикт для всего макета по одной картинке. Возможно, проблема озвученная выше, грамотно обыграна на реальном сайте, но понять это по 1 картинке нельзя. Адаптивный дизайн — норма жизни, знает ли об этом автор N-макета? Для нас останется загадкой или интригой (кому как больше нравится).
Дружит с Ubuntu, Debian, Fedora, Red Hat, Centos. Существуют версии i386, x86, x64, x86_64. Консольную утилиту можно ставить из deb-файла, через apt-get (надо указать репозиторий) или RPM.
Настраивать можно через визард (yandex-disk setup) консольной утилиты или просто редактированием конфигурации. Может работать как в режиме постоянной синхронизации через демон, так и просто выполнить синхронизацию по команде (yandex-disk sync). Можно указывать что синхронизовать, либо что не трогать, разрешить/запретить перезапись и т.п.
Базовая настройка резервного копирования с момента коннекта по ssh займет минуты 2-3.
Еще умеет работать с webdav, что в сочетании с парой утилит позволяет создать кластер из дисков, объединенный в одно дисковое пространство. Но нюансов там не мало, так что это совсем другая история.
— конфиг mod_rewrite;
— INSERT в БД по GET запросу;
— INSERT в БД без CSRF;
— определение причинно-следственной связи.
Школьнику/студенту еще простительно, но 5 лет разработки в вебе?
ps. Почитал комментарии. Товарищам, считающим, что ТС добавлял записи для счетчика просмотров — прошу прочитать первый абзац в статье чуточку внимательнее, где явно указано про форму комментариев. Хотя и с прямым взаимодействием (вставка/обновление) с БД при реализации счетчика просмотров я бы поспорил.
При отдаче страницы мы сами указываем какие данные попадают в категорию «загрузить сразу». Прописывается в заголовках, соответственно это можно делать как на статике, так и на уровне бэкенда.
Вот тут попрошу поправить меня уважаемых знатоков, но как я понял, этот процесс мы отслеживаем самостоятельно.
* Если используются CDN-сервера или кросс-доменные соединения, то прироста в производительности не будет, т.к. в этом случае браузер будет открывать новые соединения.