>> Вконтакте и Mail.ru не имеют CDN.
Тут имелось ввиду не CDN, а загрузка данных в публичную часть через эмуляцию действий пользователя.
Грубо говоря, скрипт, который подобно пользователю создаёт альбомы и загружает туда изображения.
А потом записывает сгенерированную ссылку в базу и отдаёт уже на сайте.
>> Ну не бывает бесплатного сыра
Это не из-за желания бесплатного сыра, это больше ради интереса.
Так сказать, «А что, если...»
Ну и… вдруг не мне одному пришла мысль, «как обмануть всех».
>> Используйте возможности CDN
У меня как раз где-то неделю назад пробегала одна мысль по этому поводу…
Использовать Google Drive в качестве CDN.
То есть, через API (или какими другими «хитрыми» способами) загружать фотографии товаров, видео, скрипты и т.п. на диски google и расшаривать по ссылке.
В итоге получается, в принципе, отказоустойчивая система, не нагружающая непосредственно сервер с сайтом.
При этом, места хватит, чтобы хранить достаточно много различной информации.
Можно, «на всякий случай», завести несколько аккаунтов и выбирать их в случайном порядке.
Согласен, причём это относится не только к программистам.
Какие бы навыки управления не были, всё же важно разбираться в объектной части.
Иначе без этого будут или неточные постановки задач, или же разделение мнений.
В своё время в заявках на бронирование номеров в отеле я хотел избавиться от «Уважаемый(ая)»…
Сайт был только на русском языке.
Начал изучать разные алгоритмы, правила морфологии, искать какие-то дополнения и плагины, а потом меня осенило!
Я плюнул на всё это дело — и определял пол по окончанию отчества: «ич» — мужской, «на» — женский.
Кстати, не «вич»/«вна», а именно «ич»/«на», так как есть ещё, например, «Ильич».
2 минуты — и готов алгоритм, и ничего не надо устанавливать, подключать…
А у меня возник другой вопрос…
Слово «Текст» чуть правее от центра на нижней картинке — это тоже отличие?
Или же там что-то действительно должно было быть?
>> И докупить железо — единственный надёжный вариант.
Да как сказать — порой просто index проставить надо, забыли…
Или, наоборот — не нужен был, а потом кто-нибудь в условия добавил поле, по которому индекса нет.
...
Как я вижу, основные проблемы две — это БД и нагрузка на диск.
Остальное, в принципе, всегда справляется без проблем.
Нагрузка в БД создаётся зачастую из-за неправильных запросов или отсутствующих / лишних индексов.
Нагрузка на диск — из-за некорректной работы с обращением к файловой системе.
Например, генерация превьюшек или проверка изображений товаров / новостей / блогов.
...
Вообще, я проголосовал за первый пункт, так как считаю, что оптимизация кода является немаловажной задачей.
И как раз-таки оптимизация кода способна решить большинство проблем.
Другое дело, когда код написан года 2-3-6-10 назад, и там тяжело что-то уже оптимизировать — устарело всё на корню.
Влезешь в код, постараешься оптимизировать, а в итоге не то, что не оптимизируешь, так ещё и баги вылезут…
Или же, сервер на издыхании держится, потому что от времени устал уже читать-писать.
И тут, например, SSD воткнуть или памяти «пару планок» доставить, а то memcache да PHP почти всё отъедает.
...
Моё мнение — надо каждую проблему рассматривать всем трём сторонам (хотя, можно и двум — админам и программистам).
Там уже надо решить — что быстрее, дешевле и оптимальнее — купить железо или поправить запрос.
Ведь может так случиться, что косяк в скрипте — буфер не очищается, и хоть ты 120 Гб памяти поставь — всё равно она вся забьётся.
Пункты 5 и 6, вроде как, описаны в документации. Правда на деле ни разу не приходилось передавать туда функцию.
Пункт 7 — это обычный селектор CSS, как бы он по логике и должен быть в jQuery.
Насчёт пункта 12…
Вроде как атрибут disabled=«disabled» не всегда игнорировался.
Насколько я помню, мне как раз и приходилось писать костыли, чтобы при клике на ссылку или DIV проверять, есть ли disabled или нет.
Проще говоря, событие всё же вызывалось.
Пункты 17 и 18 тоже описаны в документации.
— >>и хотя я считаю себя продвинутым JavaScript разработчиком
Хороший такой специалист :)
>> не читал исходники jQuery с начала и до конца
К слову, я тоже не читал.
Уверен, что прочитав мануал на сайте jQuery, можно ещё больше узнать интересных вещей и поведений.
P.S.:
А так…
Когда-то давно прочитал в одной из статей о jQuery, зачем в функцию вставляется аргумент с названием undefined.
И теперь всегда использую обрамление скриптов следующим кодом: (function(window, document, undefined){}(document, jQuery)),
Лично мне статья понравилась, с удовольствием почитаю ещё.
Вспомнилось, как N лет назад прикалывались над друзьями и отправляли по почте файл в 1-2 Мб.
И называли файл «Фотки.rar» или «CS_1.6.zip».
А человек его распаковать не мог, потому что места на диске не хватало.
Что касается проверки, то она какая-то странная…
Сначала происходят операции с файлом, а потом только проверяется у него расширение.
По логике, сначала должна происходить проверка входных данных, и только затем выполняться какие-то действия.
>> Пример: ЛитРес.
Как по мне, то поле ввода CVV очень неявное.
Из-за использования картинок, похожих на карту, не понятно, где поля ввода, а где картинки.
Более того, некоторые не сразу поймут, что надо вводить номер карты и дату — воспримется как просто картинка (образец).
Это из-за того, что курсор по-умолчанию ставится в поле адреса эл. почты, которое находится в самом низу формы.
Да и вообще, хотя там мало каких-то дизайнерских элементов, акцент внимания сделан только на две точки:
1) Поле ввода адреса эл. почты
2) Кнопка оплатить
И порядок действий пользователя будет таков:
1) Введёт адрес эл. почты (там моргает курсор)
2) Нажмёт кнопку «Оплатить»
Может немного не в тему, но тоже про оптимизацию скорости работы с датами.
Как-то вспомнилось…
Необходимо было сгенерировать карту сайта с количеством элементов около 500 000.
Генерация выполнялась очень медленно — порядка 30-40 секунд.
Путём анализа был выявлен участок, замедляющий код.
Это была функция date('c') — вывод даты в формате стандарта ISO 8601, напр. 2004-02-12T15:19:21+00:00.
Так как в базе хранился timestamp изменения записи, то нашлось очень лаконичное решение:
$date{10} = 'T';// Заменяем пробел между датой и временем на букву T
$date .= '+00:00';// Добавляем в конец для совместимости с форматом
Таким образом удалось сократить время ~15 раз – до 2-3 секунд.
CTRL — мизинцем
SHIFT — безымянным
T — указательным
C учётом того, что левая рука всегда лежит в левой стороне клавиатуры, всякие там CTRL нажимать, или ESCAPE, или TAB…
Хотя, может дело уже и в привычке…
>> Вконтакте и Mail.ru не имеют CDN.
Тут имелось ввиду не CDN, а загрузка данных в публичную часть через эмуляцию действий пользователя.
Грубо говоря, скрипт, который подобно пользователю создаёт альбомы и загружает туда изображения.
А потом записывает сгенерированную ссылку в базу и отдаёт уже на сайте.
>> Ну не бывает бесплатного сыра
Это не из-за желания бесплатного сыра, это больше ради интереса.
Так сказать, «А что, если...»
Ну и… вдруг не мне одному пришла мысль, «как обмануть всех».
Спасибо за скриншот, я догадывался, что будет не всё так просто.
…
Но ведь есть много других хранилищ, тот же Яндекс.Диск, dropbox и т.п.
Или, например, picasa…
А если пойти дальше, то ВКонтакте, Фото Mail.ru и т.п.
У меня как раз где-то неделю назад пробегала одна мысль по этому поводу…
Использовать Google Drive в качестве CDN.
То есть, через API (или какими другими «хитрыми» способами) загружать фотографии товаров, видео, скрипты и т.п. на диски google и расшаривать по ссылке.
В итоге получается, в принципе, отказоустойчивая система, не нагружающая непосредственно сервер с сайтом.
При этом, места хватит, чтобы хранить достаточно много различной информации.
Можно, «на всякий случай», завести несколько аккаунтов и выбирать их в случайном порядке.
Какие бы навыки управления не были, всё же важно разбираться в объектной части.
Иначе без этого будут или неточные постановки задач, или же разделение мнений.
А когда git pull завершился, я делаю git stash apply.
Если тут возникают конфликты, исправляю.
В итоге у меня мой коммит единственный и идёт всегда после мерджа с master'ом.
Сайт был только на русском языке.
Начал изучать разные алгоритмы, правила морфологии, искать какие-то дополнения и плагины, а потом меня осенило!
Я плюнул на всё это дело — и определял пол по окончанию отчества: «ич» — мужской, «на» — женский.
Кстати, не «вич»/«вна», а именно «ич»/«на», так как есть ещё, например, «Ильич».
2 минуты — и готов алгоритм, и ничего не надо устанавливать, подключать…
Слово «Текст» чуть правее от центра на нижней картинке — это тоже отличие?
Или же там что-то действительно должно было быть?
Да как сказать — порой просто index проставить надо, забыли…
Или, наоборот — не нужен был, а потом кто-нибудь в условия добавил поле, по которому индекса нет.
...
Как я вижу, основные проблемы две — это БД и нагрузка на диск.
Остальное, в принципе, всегда справляется без проблем.
Нагрузка в БД создаётся зачастую из-за неправильных запросов или отсутствующих / лишних индексов.
Нагрузка на диск — из-за некорректной работы с обращением к файловой системе.
Например, генерация превьюшек или проверка изображений товаров / новостей / блогов.
...
Вообще, я проголосовал за первый пункт, так как считаю, что оптимизация кода является немаловажной задачей.
И как раз-таки оптимизация кода способна решить большинство проблем.
Другое дело, когда код написан года 2-3-6-10 назад, и там тяжело что-то уже оптимизировать — устарело всё на корню.
Влезешь в код, постараешься оптимизировать, а в итоге не то, что не оптимизируешь, так ещё и баги вылезут…
Или же, сервер на издыхании держится, потому что от времени устал уже читать-писать.
И тут, например, SSD воткнуть или памяти «пару планок» доставить, а то memcache да PHP почти всё отъедает.
...
Моё мнение — надо каждую проблему рассматривать всем трём сторонам (хотя, можно и двум — админам и программистам).
Там уже надо решить — что быстрее, дешевле и оптимальнее — купить железо или поправить запрос.
Ведь может так случиться, что косяк в скрипте — буфер не очищается, и хоть ты 120 Гб памяти поставь — всё равно она вся забьётся.
habrahabr.ru/post/161009/#comment_5546481
Могу сказать, что PHPStorm нередко не может сделать commit при исправлении конфликтов. Только через консоль получается.
Ну и ещё git status, git -rm --cached
Наверно, всё дело в том, что примеры неправильные.
Надо не с CSS-селекторами оперировать, а с переменными или объектами типа document, window.
Ведь, общепринято использовать $('.parent .child').on(...);
А вот если $(document).on($link, ...), тогда да…
Пункт 7 — это обычный селектор CSS, как бы он по логике и должен быть в jQuery.
Насчёт пункта 12…
Вроде как атрибут disabled=«disabled» не всегда игнорировался.
Насколько я помню, мне как раз и приходилось писать костыли, чтобы при клике на ссылку или DIV проверять, есть ли disabled или нет.
Проще говоря, событие всё же вызывалось.
Пункты 17 и 18 тоже описаны в документации.
— >>и хотя я считаю себя продвинутым JavaScript разработчиком
Хороший такой специалист :)
>> не читал исходники jQuery с начала и до конца
К слову, я тоже не читал.
Уверен, что прочитав мануал на сайте jQuery, можно ещё больше узнать интересных вещей и поведений.
P.S.:
А так…
Когда-то давно прочитал в одной из статей о jQuery, зачем в функцию вставляется аргумент с названием undefined.
И теперь всегда использую обрамление скриптов следующим кодом: (function(window, document, undefined){}(document, jQuery)),
www.miastogier.pl/baza/Encyklopedia/gry/Commandos3KierunekBerlin_PC/Recenzja/rec_Commandos3_recenzja_04.jpg
www.igropoisk.com/files/screen/18973/1.jpg
Вспомнилось, как N лет назад прикалывались над друзьями и отправляли по почте файл в 1-2 Мб.
И называли файл «Фотки.rar» или «CS_1.6.zip».
А человек его распаковать не мог, потому что места на диске не хватало.
Кстати, может кому пригодится…
>> $ext = strtolower($ext[count($ext)-1]);
$ext = strtolower(end($ext))
Что касается проверки, то она какая-то странная…
Сначала происходят операции с файлом, а потом только проверяется у него расширение.
По логике, сначала должна происходить проверка входных данных, и только затем выполняться какие-то действия.
Как по мне, то поле ввода CVV очень неявное.
Из-за использования картинок, похожих на карту, не понятно, где поля ввода, а где картинки.
Более того, некоторые не сразу поймут, что надо вводить номер карты и дату — воспримется как просто картинка (образец).
Это из-за того, что курсор по-умолчанию ставится в поле адреса эл. почты, которое находится в самом низу формы.
Да и вообще, хотя там мало каких-то дизайнерских элементов, акцент внимания сделан только на две точки:
1) Поле ввода адреса эл. почты
2) Кнопка оплатить
И порядок действий пользователя будет таков:
1) Введёт адрес эл. почты (там моргает курсор)
2) Нажмёт кнопку «Оплатить»
Как-то вспомнилось…
Необходимо было сгенерировать карту сайта с количеством элементов около 500 000.
Генерация выполнялась очень медленно — порядка 30-40 секунд.
Путём анализа был выявлен участок, замедляющий код.
Это была функция date('c') — вывод даты в формате стандарта ISO 8601, напр. 2004-02-12T15:19:21+00:00.
Так как в базе хранился timestamp изменения записи, то нашлось очень лаконичное решение:
$date{10} = 'T';// Заменяем пробел между датой и временем на букву T
$date .= '+00:00';// Добавляем в конец для совместимости с форматом
Таким образом удалось сократить время ~15 раз – до 2-3 секунд.
Решение дал выше:
habrahabr.ru/post/223065/#comment_7594911
В то время уникальная возможность среди других браузеров.
SHIFT — безымянным
T — указательным
C учётом того, что левая рука всегда лежит в левой стороне клавиатуры, всякие там CTRL нажимать, или ESCAPE, или TAB…
Хотя, может дело уже и в привычке…