А я корни иногда из билетиков извлекаю ;)
Чем дальше ехать — тем больше знаков после запятой)
Теперь и к 100 буду приводить — это менее алгоритмизировано =)
Если присмотреться, то под тегами можно увидеть стрелочку вверх, которая эквивалентна вашему комментарию.
И в любом случае, такой комментарий информационнообделенн и повышает энтропию…
Пока что сыро )
Стрелку лучше сверху, нужно запоминать положение для всех страниц, надо убрать #… И сделать закругленные уголки не так уж сложно — правильные margin'ы или еще чуть-чуть js…
Вот до такого объединение тегов никогда не должно доходить! И в этом-то основная проблема — слишком широки смыслы и области применения тегов-терминов-названий…
Sphinx — «поиск», но ни в коем случае не «SEO»!
Код userscript'а запускается как код указанный в head, если я ничего не путаю, т.е. фактически сразу после инициализации страницы.
Для этого и используют что-то вроде while(! document.body){} и т.п. ;) И это позволяет обрабатывать элементы, как только они появляются в DOM, а не после окончательной загрузки всего дерева. Если этим уметь пользоваться, конечно =)
В том-то и дело, что DOMContentLoaded иногда слишком поздно…
Видел в одном из скриптов цикл, который обходил все уже существующие элементы (только нужные скрипту, конечно, но не суть), обрабатывал их и ставил специальный класс, чтобы на следующей итерации пропустить обработанные элементы. Прерывался скрипт как раз на DOMContentLoaded ;)
Вот только я в своём скрипте воссоздать это не смог :(
эх… я не хотел вас никак оскорбить.
Мне очень интересны и новы оказались некоторые сведения, вам спасибо!
Принуждать вас к написанию литературной статьи я не мог и не собирался. Лишь указал на недостатки, может вы в будущем прислушаетесь. Ведь всё-таки это статья для подачи какой-то информации, а не отрывки из беседы с другом-программистом.
Не принимайте так близко :)
Это был просто пример, возможно и неудачный к тому же.
Статья осталась в том же обрывочном формате — прописная буква не сделает слово началом предложения, если оно таковым не является…
COUNT(*) vs COUNT(column_name)
Замечал не раз, что многие считают, что COUNT(*) это алиас COUNT(column_name). Это совершенно не так.
Во-первых, эти запросы могут возвращать разные результаты. Такое может проявляться когда столбец column_name может содержать NULL значения. Т.е. конструкция COUNT(column_name) вернет кол-во записей с column_name IS NOT NULL.
Во-вторых, эти запросы выполняются с разной скоростью. Например, такой запрос
SELECT
SQL_NO_CACHE count(tli.`type`)
FROM
`tx_localrep_images` as tli
WHERE
tli.uid > 500;
может выполняться гораздо дольше, чем
SELECT
SQL_NO_CACHE count(*)
FROM
`tx_localrep_images` as tli
WHERE
tli.uid > 500;
т.к. запрос, использующий COUNT(*), при наличии индекса по полю tli.uid будет использывать покрывающий индекс и, соответственно, выполнится очень быстро. Первый же запрос будет искать COUNT методом ROW SCAN, о чем и говорит «Extra: USING WHERE» в EXPLAIN этого запроса.
На самом деле можно сделать так, чтобы и первый запрос использовал индекс, добавив к данной таблице покрывающий индекс cover_key(uid, type). Но, ИМХО, лучше использовать COUNT(*), чем вводить дополнительный индекс для одного единственного запроса.
Ну в принципе тут не так много-то и надо для отличных заметок! )
Добавить подзаголовки для разбиения.
И строить логику «повествования», мысли организовывать, оформлять их в абзацы с более-менее законченным смыслом, без разрывов посреди предложения.
Сложно это выразить, посмотрите хорошие статьи хотя бы прямо здесь, на хабре.
Смотреть-то хорошо =) Некоторое вещи действительно интересны.
Только вы бы статьи свои правили, приводили их к нормальному стилю.
Пример — кусок про ip-адреса. «соответственно если мы хотим, скажем, выполнить поиск...» якобы продолжает предыдущую мысль, на самом деле начиная новую, и то как-то непонятно, с маленькой буквы, как будто у вас что-то удалилось…
Ну и такая рваность и разрозненность кругом.
При уменьшении окна горизонтальный скрол обрезает справа и окошко подергивается слегка.
3.0.1
Чем дальше ехать — тем больше знаков после запятой)
Теперь и к 100 буду приводить — это менее алгоритмизировано =)
И в любом случае, такой комментарий информационнообделенн и повышает энтропию…
Стрелку лучше сверху, нужно запоминать положение для всех страниц, надо убрать #… И сделать закругленные уголки не так уж сложно — правильные margin'ы или еще чуть-чуть js…
vCard
Sphinx — «поиск», но ни в коем случае не «SEO»!
Для этого и используют что-то вроде while(! document.body){} и т.п. ;) И это позволяет обрабатывать элементы, как только они появляются в DOM, а не после окончательной загрузки всего дерева. Если этим уметь пользоваться, конечно =)
Видел в одном из скриптов цикл, который обходил все уже существующие элементы (только нужные скрипту, конечно, но не суть), обрабатывал их и ставил специальный класс, чтобы на следующей итерации пропустить обработанные элементы. Прерывался скрипт как раз на DOMContentLoaded ;)
Вот только я в своём скрипте воссоздать это не смог :(
Мне очень интересны и новы оказались некоторые сведения, вам спасибо!
Принуждать вас к написанию литературной статьи я не мог и не собирался. Лишь указал на недостатки, может вы в будущем прислушаетесь. Ведь всё-таки это статья для подачи какой-то информации, а не отрывки из беседы с другом-программистом.
Не принимайте так близко :)
Статья осталась в том же обрывочном формате — прописная буква не сделает слово началом предложения, если оно таковым не является…
Замечал не раз, что многие считают, что COUNT(*) это алиас COUNT(column_name). Это совершенно не так.
Во-первых, эти запросы могут возвращать разные результаты. Такое может проявляться когда столбец column_name может содержать NULL значения. Т.е. конструкция COUNT(column_name) вернет кол-во записей с column_name IS NOT NULL.
Во-вторых, эти запросы выполняются с разной скоростью. Например, такой запрос
SELECT SQL_NO_CACHE count(tli.`type`) FROM `tx_localrep_images` as tli WHERE tli.uid > 500;может выполняться гораздо дольше, чем
SELECT SQL_NO_CACHE count(*) FROM `tx_localrep_images` as tli WHERE tli.uid > 500;т.к. запрос, использующий COUNT(*), при наличии индекса по полю tli.uid будет использывать покрывающий индекс и, соответственно, выполнится очень быстро. Первый же запрос будет искать COUNT методом ROW SCAN, о чем и говорит «Extra: USING WHERE» в EXPLAIN этого запроса.
На самом деле можно сделать так, чтобы и первый запрос использовал индекс, добавив к данной таблице покрывающий индекс cover_key(uid, type). Но, ИМХО, лучше использовать COUNT(*), чем вводить дополнительный индекс для одного единственного запроса.
Добавить подзаголовки для разбиения.
И строить логику «повествования», мысли организовывать, оформлять их в абзацы с более-менее законченным смыслом, без разрывов посреди предложения.
Сложно это выразить, посмотрите хорошие статьи хотя бы прямо здесь, на хабре.
Только вы бы статьи свои правили, приводили их к нормальному стилю.
Пример — кусок про ip-адреса. «соответственно если мы хотим, скажем, выполнить поиск...» якобы продолжает предыдущую мысль, на самом деле начиная новую, и то как-то непонятно, с маленькой буквы, как будто у вас что-то удалилось…
Ну и такая рваность и разрозненность кругом.