Женя Остроушко

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

1. Мобильные телефоны — 320px. Ориентируемся на viewport айфона, т.к. он самый маленький. У современных андроидов вьюпорт больше, поэтому их игнорируем (растянется на верстке).

2. Планшеты — 768px. Опять-таки ориентируемся на айпад в портретной ориентации , т.к. у андроид планшетов вьюпорты обычно имеют размер от 800×1200 или совпадают с айпадом. Планшеты с вьюпортом 600×1024px устарели. К тому же ничего страшного, если в вертикальной ориентации сайт на таком планшете будет выглядеть как на мобильнике, а в горизонтальной ориентации — как на десктопе.

3. Десктоп и планшеты в ландшафтной ориентации — 1000px. Почему 1000, а не 1024: первое, в настольных браузерах полоса прокрутки съедает (обычно) 18px ширины; второе, от 1000px верстальщику удобнее расчитывать размеры в процентах, а до 1024 все равно растянется при верстке.

В принципе, этого достаточно, чтобы верстальщик справился.

Если дизайн не имеет максимальной ширины и тянется от края до края окна браузера, то на усмотрение дизайнера можно нарисовать еще один или несколько эскизов для более широких экранов.

В каком порядке рисовать? Смотря как поставлено тех.задание. Чаще всего в задании описан полный функционал для настольной версии. Тогда проще нарисовать дизайн под 1000px и перекомпоновать под 768 и 320, выбросив или упростив по пути менее значимые элементы сайта. Т.е. двигаться от сложного к простому.

Верстать при этом удобнее от меньшего экрана к большему (от простого к сложному). При mobile first верстальщику приходится дописывать новые стили для бóльших экранов поверх базовой версии в 320px вместо того, чтобы обнулять написанные для настольных браузеров стили. В результате для мобильника css весит меньше и парсится быстрее.

Причин появления ошибки No input file specified несколько:
1. У вас не установлена переменная SCRIPT_FILENAME в конфиге nginx;
2. Задан неправильный аргумент root в конфиге nginx;
3. Переменная open_basedir в /etc/php5/fpm/php.ini или в конфиге php5-fpm пула содержит путь, который не соответствует аргументу root в конфиге nginx;
4. Пользователь с правами которого работает php5-fpm или конкретный пул php5-fpm не имеет прав доступа к каталогу или файлу с php-скриптом;

Пример правильного конфига nginx + php5-fpm:

server {
....
root /var/www/mysite.com;
index index.php index.html index.htm;

location / {
        try_files $uri $uri/ =404;
}
location ~ \.php$ {
        try_files $uri = 404;
        fastcgi_pass unix:/var/lib/php5-fpm/mysite.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
}
...
}

В функцию передается число: 1.3500, 1.36, 1.2...
Функция должна возвращать количество цифр после точки

Первый шаг - выявление направленности проекта:

• коммерческий
  
• информационный
  
• энциклопедический
  
• социальная сеть и прочее
  

Далее, после того как определились с типом ресурса, выявляем важнейшие для его оптимизации факторы ранжирования. Так, например, для коммерческих проектов во главе угла стоят коммерческие факторы ранжирования, а вот для информационного проекта необходимо учитывать полноту раскрытия информации, стиль подачи и многое другое, подробнее можно почитать в этой статье на Хабре.
​
Далее есть список факторов которые необходимо учитывать всем ресурсам, это технические, семантические и поведенческие факторы.
​
Для начала необходимо подготовить фундамент - провести подробный анализ техническихфакторов помогут такие программы как Netpeak Spider или Screaming Frog (программ конечно многое множество, но эти используют чаще всего). Но, к сожалению, тулсами можно проверить не все и необходимо будет изучить матчасть и проверять многие технические аспекты руками.
​
Затем переходим к семантике, это очень сложный вопрос который лучше будет описать в другом ответе, но, в двух словах, необходимо убедиться что у всех страниц сайта заполнены важные элементы семантики (title, h1 и прочее) и они соответствуют контенту страницы.
​
После, к UX сайта, четко продумывая взаимодействие пользователя и максимальное для него удобство. Тут же сразу учтем и часть коммерческих факторов, и оформление контента и прочее что напрямую связано с поведением пользователя.
​
В финале мы получим идеально внутренне оптимизированный ресурс и можно будет приступать к внешней оптимизации.
​
Старайтесь делать все максимально полезным для пользователя. Органичность содержимого сайта, реальная польза входящей ссылки для пользователя на стороннем ресурсе и прочее белое SEO это то к чему надо стремиться!
​
Яндекс подсказывает как развивать сайт белыми методами и чтобы он был полезен пользователю. Все материалы можно найти:
В Блоге Вебмастеров
На канале Академии Яндекса
В Хелпе Яндекс Вебмастера

https://firebase.google.com/

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

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

А сервер хранит эту строку у себя, с привязкой к записи пользователя.

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

Первый вопрос: За какой период их надо хранить? Вечно? А смысл в этом есть?

Второй вопрос: сколько УЖЕ записей посетителей и за какой период. "Рано или поздно" - это может быть и через неделю, и через год, и никогда.

Если не ответить на эти вопросы заранее - может получиться так, что ты решаешь задачу, которую решать не нужно, потому что имеющихся средств (mysql или даже хранение логов в CSV) достаточно.

Тоже попал под блокировку в DO

Выход простой
Топаете в любого отечественного хостера, покупаете самую дешевую VDS с хорошим каналом и настраиваете reverse proxy на nginx приблизительно с таким конфигом:

server {
        listen                  80;
        server_name             domain.ru;
        
        location / {
                proxy_pass http://111.111.111.111:80;
                proxy_connect_timeout                           60;
                proxy_send_timeout                                      60;
                proxy_read_timeout                                      60;
                proxy_redirect                                          off;
                proxy_buffer_size                                       4k;
                proxy_buffers                                           4 32k;
                proxy_busy_buffers_size                         64k;
                proxy_temp_file_write_size                      10m;
                proxy_set_header        Host                    $host;
                proxy_set_header        X-Real-IP               $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

где 111.111.111.111 это IP адрес вашего дроплета в DO

и для https сайтов

server {
        listen                  443;
        ssl                     on;
        server_name             domain.ru;
        ssl_certificate      /etc/nginx/ssl/domain.ru.crt;
        ssl_certificate_key  /etc/nginx/ssl/domain.ru.key;
        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers  "RC4:HIGH:!aNULL:!MD5:!kEDH";

        location / {
                proxy_pass https://111.111.111:443;
                proxy_connect_timeout                           60;
                proxy_send_timeout                                      60;
                proxy_read_timeout                                      60;
                proxy_redirect                                          off;
                proxy_buffer_size                                       4k;
                proxy_buffers                                           4 32k;
                proxy_busy_buffers_size                         64k;
                proxy_temp_file_write_size                      10m;
                proxy_set_header        Host                    $host;
                proxy_set_header        X-Real-IP               $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        }

}

такая вот у нас замечательная, страна, конечно...

Честно говоря, работа похожа на то, что ты скачал готовый шаблон и попытался его освоить и переверстать под адаптив. Видно, что какие-то вещи, типа слайдера, эффектов слишком хорошо сделаны, продуманы, а в исходники смотришь, а там то сасс файлы, то scss.. то скрипт называется common, то script.min.js, хотя это два одинаковых и не минифицированных скрипта. Видно, как хорошо сделана десктопная версия, и как плохо - мобильная. Взять то же меню в мобильной версии: появляется панель с кнопками, в которой не продолжена стиллистика сайта, нет эффектов наведения. Ошибки новичка. Но вот на десктопной версии у тебя очень удачно получилось продумать эффекты наведения.. Хмм, что мешало сделать так же в меню?! Падазрительнааа --
Ну и самое важное: где история изменений в гите? Зачем выкладывать репозиторий, если в нем нет истории?
Итог: работу найти не можешь, поэтому пишешь сюда, считая, что тостер - это неплохая площадка для само-рекламы. При этом нихера не сделано по существу, и не видно как ты работал. и ты ли вообще.
В последнее время много таких людей стало, кто ищет работу на тостере под предлогом вопроса: что я делаю не так, как устроиться на работу, почему меня никто не берет, ну возьмите уже наконец меня, прям тут.. Тьфу. Вопросов таких целая куча и ответов к ним тоже. Но искать людям лень. Да и хватит себя жалеть. Нарабатывай портфолио в гите, с ИСТОРИЕЙ! Не пудри мозги людям.
Но! Если это и впрямь твоя верстка, то можешь смело искать себе работу, хотя бы на поддержку готовых проектов. Я уже через 3 месяца после начала учебы нашла, на 23к не в Москве, а в райцентре таксказать. Главное терпение и усё будет.