socket.bufferType = "arraybuffer";
socket.onmessage = (event) => {
// event.data является строкой (если текст) или arraybuffer (если двоичные данные)
};
создать папку original_photos прям на хостинге, и запретить её сканирование поисковыми системамиЕсли Вы не будете давать прямых ссылок на эту папку, вероятность того, что поисковые системы там что-то проиндексируют - стремиться к нулю.
Или есть какие-то другие грамотные варианты?Если места на хостинге хватает - почему бы и нет? Если не хватает сохраняйте на каком-нибудь облачном диске (вариантов масса). А что бы совсем хорошо - можете сохранить файлы и там и там.
сервер базы стоит на SSDЯ думаю, где стоит сам сервер - особой разницы нет.
Меня интересует стоит ли хранить сами базы на SDD или лучше их перенести на HDD для продления жизни SDD?Для ответа на этот вопрос, нужно оценить следующие факторы:
Стоит отметить что базу используя для личной разработки.Дочитал до этого пункта и... Из личного опыта могу рассказать Вам одну историю... Есть у нас сервер 1U, купленный изначально "для работы", потом мы его отдали под проект. В сервере среди прочего стоит SSD, самый обыкновенный, на 120Гб, из числа тех что стоят сейчас в районе 1500руб., стоит он там уже более 2-х лет (с того момента как мы его отдали проекту), ежедневно и беспрерывно, 24х7 диск "молотит" база достаточно крупного проекта (и сам проект стоит там же), изначально было много опасений на тему того, что диск не проживёт там и месяц... но, любопытство всё же пересилило и мы решили попробовать. Результат - по прошествии 2+ лет "здоровье" диска в районе 74%, думаю ещё года 3 он там проживёт за милую душу. Единственное отличие нашего диска от тех, что продаются сейчас - у него MLC-память, но что-то мне подсказывает, что этот факт никак не даёт диску сколь-нибудь фантастическую живучесть по сравнению со всеми остальными.
Например, сборщик Gulp поднимает локальный сервер по адресу localhost:3000. Чем это может помочь при тестировании верстки?Насколько я помню, сам Gulp ничего не поднимает, но это не суть... Сервер, локальный, нужен как минимум для возможности указания корректных по отношению к корню сервера путей, для тех же картинок, например:
<img src="/img/image1.png" alt="#" />
- без локального сервера будет работать "никак". Уже этого факта достаточно, что бы этот самый сервер поднимать :) <button/>
можно выставить любые параметры, в т.ч. касающиеся его позиционирования.display: block;
, а самой кнопке margin: auto;
или же отцентрировать её через flex
... Почему лучше добавлять классы в контейнер и создавать их из контейнера а не через new?Откровенно говоря, вопрос звучит аки "почему молоток лучше чем пассатижи?".
но еще и панель управления в придачу.Панель обычно неплохо так потребляет ресурсы, особенно если это задохный VPS с 1-м виртуальным процессором и 0.5-1Гб памяти.
который оказался слабее, еще установили OPCache, xDebug (не запускается при каждом запросе)OPCache если мне памяти не изменяет давно уже ставиться вместе с PHP по умолчанию. А вот установленный XDebug на боевоем сервере... боюсь даже представить, что употребляет автор подобных решений.
Вопрос:С точки зрения логики, безопасности, здравого смысла и ряда прочих факторов, включая архитектурные особенности (по части хранения таблиц в рамках файловой системы) самих БД - я хранил подобные данные в разных БД. Но, с учётом того, что "сотня тысяч" строк, это по большому счёту "пшик" и база уровня "шаред-хостинг" (думаю, ещё даже не VPS) - то для удобства можно хранить всё это и в одной базе.
Какую архитектуру базы данных создать, под каждый сайт отдельные таблицы или отдельную базу данных под каждый мгаазин или сотни тысяч товаров в одной держать. Кто работал с конструторами сайтов, какая у них база данных под каждого клиента. И стоит ли вообще использовать mysql или стоит рассмотреть другого вариант? Как бы вы построили базу данных, если бы таких магазинов было 100 и более.
var test = 0;
$.each(b, function(i, item) {
test = test+ item;
alert(test); // Выводит
});
alert(test);
var test = 0;
$.each(b, (i, item) => {
test = test+ item;
alert(test); // Выводит
});
alert(test);
2. Передавать какой-то секретный ключ с сервера АПИ и проверять его на сервере статистики. Этот вариант мне кажется наиболее удобным, но в каком виде его хранить и как передавать?Видится мне, что это самый разумный вариант. Список адресов - не слишком надёжен и не особо логичен.
1. Как помнится из коробки что-то было для работы с формами, но потом выкинули?Так и есть, выкинули за ненадобностью подобных хвостов в основном фреймворке. В том смысле, что этот хвост ещё и поддерживать нужно...
Выходит по дефолту работаем с формами на чистом HTML (+blade)? Может какие-то пакеты юзаете?Можно так, можете пользоваться теми формами которые выпилили, можете воспользоваться вариантом аки symfony, ещё можно тут поискать другие варианты.
2. Как правильно работать при CRUD c C и U, т.е. нужно два раза форму показать и это разные вьюхи? или форму в одну вьюху закидываете и там рулите?Всё индивидуально. В общей сложности, при простых вариантах - создавать разные файлы форм не обязательно, при "C" можете создавать ту же форму что и при "U", передавая туда пустую модель.
Подойдёт ли такой домен для международного сайтаПочему нет? Для международного сайта подойдёт любой домен не привязанный к конкретной стране. Лично я страны "сайт" не припоминаю...
А регистрация данного домена стоит лишь 64 рубля.А продление наверное пару-тройку тысяч :)) И наверное это reg.ru опять расщедрился? К слову, у них много доменов по 64руб., со стоимостью продления очень далёкой от стоимости регистрации...
Но это повысит нагрузку на серверНе совсем корректное утверждение. Сокеты тоже дают некоторую нагрузку на сервер + по большому счёту - всё что угодно может повысить нагрузку на сервер. Вопрос не в нагрузке на сервер а в том, в каких величинах эта нагрузка выражается и насколько она критична в каждом конкретном случае.
Чем это хуже подхода - когда вся логика распологается в сервисах, и в целом чем плох такой подход?Он ничем не хуже и не лучше. Пакеты - это одно, сервисы - другое, а Вы их зачем-то "складываете в одну корзину". Что по сути своей представляет пакет? - пакет - это некий модуль, решающий какую-то конкретную задачу, поддерживаемый и обслуживаемый конкретным веднором. В массе своей пакеты никак не привязаны к тому, где и как они будут использоваться. То есть, пакет - это некий набор общей логики, процессов и т.д. для решения какой-то задачи (или набора схожих/связанных задач), например для обработки изображений.
подскажите пожалуйста , есть ли где-то svg код иконок для html?В сети их как грязи, например тут.
Сейчас использую awesomeТам тоже несколько тысяч.
но хотелось бы убрать лишние скриптыНе вижу ни одной помехи для этого.
и что лучше awesome или svg кодFontAwesome - можно скачать отдельно, в SVG формате (каждую иконку отдельно).
на странице по 20-30 таких кодов может быть?С точки зрения сокращения обращений к серверу - встраивать SVG в страницу - лучше. С точки зрения читаемости такого кода - думаю, хуже.
Но когда захожу по ссылке, выходит:Это значит, что ОпенСерер отдаёт дефолтный сайт. Иными словами, проблема либо в том, что дефолтный сайт отличается от того, который Вы хотите показать кому-то, либо в том, что у вас на сервере не зарегистрирован тот домен, который Вы указали в примере выше.