конечно я не знаю и не могу знать обо всех происходящих процессах, но я не хочу, чтобы программы жили своей собственной жизнью и чтобы однажды Chrome 3495 решил сменить мою Win7 на Android потому что его разработчикам показалось это правильным.
я не против автообновлений вообще (использую полностью автоматические обновления на нескольких компах).
но я против них на мом компе. мне не впадлу жмакнуть кнопку «обновить», когда я сочту это нужным (например когда у меня нет строчной работы и я не готов к неожиданным поломкам) и я буду готов к тому, что что-то может сломаться и буду знать причину этой поломки.
«работает — не трожь». это касается не только кривых рук, но и автоапдейтов программ.
«Автообновление — это одна из убийственных особенностей Chrome.»
Отличная фраза. полностью с ней согласен, т.к. эта одна из тех фич (есть ещё две), из-за которой я больше никогда его себе ставить не буду :)
Я сам хочу решать, что происходит на моём компьютере.
> Вот ёмкостной тачскрин, отрабатывающий несколько нажатий одновременно — крутейшее изобретение,
Фигня это, а не крутейшее изобретение.
На данном этапе технического развития это абсолютно логичное продолжение этого развития (эволюция). Как вторая кнопка мышки и много ещё аналогичных «изобретений».
Это «изобретение» появилось бы если не «сейчас», то через пол года совершенно точно.
> Изъяном я назову abuse системы, но всю ее целиком.
Потому систему целиком и называют изъяном, что пока она существует, её будут abuse-ить. И избавиться от этого изъяна, сохранив систему, невозможно.
В проверке валидности email фигурирует "[A-z0-9]"
но A-z совсем не то-же самое, что и A-Za-z, т.к. включает в себя следующие символы: [ ] ^ _ ` и \ (откройте charmap)
Как минимум это не соответствует regex проверки валидности домена, приведённого выше (где эти символы не включены в разрешённый набор), а как максимум это неверно, т.к. адреса вида name@do\main.ru, name@do[main.ru и name@do]main.ru не валидны.
Я email-ы проверяю такой регуляркой (с ключиком i, поэтому не пишу a-zA-Z): ^(?:[-a-z\d\+\*\/\?!{}`~_%&'=^$#]+(?:\.[-a-z\d\+\*\/\?!{}`~_%&'=^$#]+)*)@(?:[-a-z\d_]+\.){1,60}[a-z]{2,6}$
Ссылку страницу со сравнением результатов проверки разных email этой регулярки и регуляркой по rfc822 (вам уже привели этот 6-КБ regex) я не даю, т.к. опасаюсь хабраэффекта :)
а «линзы» надо переставить у пары арендованных очков прямо в зале :)
правда те, кому после вас такие очки достанутся — будут ругаться :)
P.S. у меня тоже после 3D глаза болят, хотя зрение без отклонений и раньше (лет 5 назад) не болели. надо будет для проверки у своих очков «линзы» переставить, благо такие очки у нас по $1 стоят и приходить можно со своими.
P.S. когда обсуждается, «микроскопом А или микроскопом Б лучше забивать гвозди?», то с бредовым предложением забыть про микроскоп (тип таблиц) и воспользоваться молотком (индексами) в дискуссию лучше не влезать, ибо она тут не к месту.
ну почему-же… чуть лучше станет если добавить, например, вот такой составной индекс:
create index ix_calls_0 on calls (cost, user_id);
а ещё у меня чуть быстрее получилось, если запрос переписать так:
SELECT COUNT(cost) FROM calls INNER JOIN (SELECT id FROM users WHERE sex = 'M') a ON (calls.user_id = a.id) WHERE calls.cost > %d;
последнее ускорило и join MyISAM+MyISAM и InnoDB+InnoDB (извращения типа MyISAM+InnoDB я не проверял)
спасибо за пояснение. лично я, при таком сравнении циферок, как приводится в статье, этого сразу не понял (тупой, да).
в таком представлении подобное тестирование имеет смысл для случаев, когда не представляется возможным добавить такие индексы, чтобы join их использовал.
я попытался воспроизвести тест и попробовал добавить индекс на calls.user_id. и от него стало только хуже (глядя на результаты explain становится понятно почему).
однако составной индекс на столбцы user_id + cost решает проблему для данного запроса и он начинает выполняться существенно быстрее (тоже понятно почему). у меня время выполнения запроса с 100% для MyISAM уменьшилось в 40 раз (с ~130 сек до ~3 сек).
т.е. я продолжаю считать, что нужно думать над теми запросами, которые будут выполняться и создавать необходимые индексы, которые будут помогать выполнять запросы (и это касается не только join-ов).
если есть запросы, которые не могут быть оптимизированы добавлением индексов, и при этом данные запросы приводят к полному сканированию таблиц с миллионами записей — самое время вмешиваться в архитектуру.
P.S. ничего против InnoDB я не имею. сказанное мной выше относится и к ним.
> запросы прогонялись несколько раз, чтобы убедиться, что всё попадает в кеш.
Если хочется тестировать скорость JOIN (пусть и сферическую, без индексов, в вакууме), то правильнее было-бы отключить кэширование (опциями в запросе), чтобы тестировать именно скорость JOIN, а не то, какой именно запрос кэшируется и как быстро работает кэш в разных случаях.
категорически согласен: смысла использовать SQL и при том не использовать индексы — ноль.
и вместо чтения исследований производительности без использования индексов (которое возможно и имеет какой-то сугубо теоретический смысл), новичкам лучше почитать про использование этих самых индексов. этот способ оптимизации гораздо лучшие, чем конвертирование табличек MyISAM <=> InnoDB.
вообще каналы от австралии до остального мира не фонтан.
а сайты да, они по российским меркам полное дерьмо (особенно в плане дизайна), но блин, они есть у всех гос организаций и у каждого третьего сантехника. и, что касается организаций, они не просто есть для галочки, но они работают и там есть нужная информация.
в нашей австралийской деревне с ямами, а так-же другими проблемами борятся так:
— через форму обратной связи на сайте города отправляется сообщение о проблеме. там-же сразу указывается, что за проблема: яма, хреново работающий водослив и т.п. как альтернатива — можно позвонить и сообщить об этом по телефону (но просят по телефону беспокоить только в случае серьёзных проблем).
— через несколько дней приедут и посмотрят на месте, что и как (приезжает один человек). ещё через нескольких дней — фиксят (понятно, что сложные случаи фиксятся дольше).
вроде-бы и всё, но… раз в месяц среди сообщивших о проблеме выбирают несколько человек, которым за содействие выдают бабло (кажется $100), типа в знак благодарности за сообщение о проблеме, что мол помог городу :)
P.S. я о проблеме у дома сообщал, приехали и пофиксили быстро (но не полностью, т.к. для полного устранения проблемы надо менять большой водослив), по моему дня за 3. после этого сообщили, что отправили заявку на полное устранение проблемы (типа когда будут водосливы менять где-то в районе — сделают и у нас). но в лотерею не выиграл :)
off: я не слышал, чтобы на «крыле» приземлялись на деревья, а в случае зависания на дереве при прыжках на круглых-армейских учат открывать запаску и по её стропам спускаться вниз. и лично я спускался с дерева именно так :)
автор топика немеряно крут.
я проучился в институте (МИЭТ) почти 6 лет и изучал как раз химию и физику изготовления интегральных схем. уже мало что помню, но тем не менее даже у изучаемых тогда 0.1 мкм техпроцессов проблем с дефектами немеряно. и это в промышленных условиях, где доступны большие печи (в них более равномерный нагрев), шлифовальные/полировальные машины в чистых зонах, литографическое оборудование и любые необходимые химикаты высокой степени очистки.
в общей непросто это будет.
imageshack.us/photo/my-images/43/netscape3about.png/
imageshack.us/photo/my-images/820/netscape3blank.png/
конечно я не знаю и не могу знать обо всех происходящих процессах, но я не хочу, чтобы программы жили своей собственной жизнью и чтобы однажды Chrome 3495 решил сменить мою Win7 на Android потому что его разработчикам показалось это правильным.
я не против автообновлений вообще (использую полностью автоматические обновления на нескольких компах).
но я против них на мом компе. мне не впадлу жмакнуть кнопку «обновить», когда я сочту это нужным (например когда у меня нет строчной работы и я не готов к неожиданным поломкам) и я буду готов к тому, что что-то может сломаться и буду знать причину этой поломки.
«работает — не трожь». это касается не только кривых рук, но и автоапдейтов программ.
Отличная фраза. полностью с ней согласен, т.к. эта одна из тех фич (есть ещё две), из-за которой я больше никогда его себе ставить не буду :)
Я сам хочу решать, что происходит на моём компьютере.
Фигня это, а не крутейшее изобретение.
На данном этапе технического развития это абсолютно логичное продолжение этого развития (эволюция). Как вторая кнопка мышки и много ещё аналогичных «изобретений».
Это «изобретение» появилось бы если не «сейчас», то через пол года совершенно точно.
> Изъяном я назову abuse системы, но всю ее целиком.
Потому систему целиком и называют изъяном, что пока она существует, её будут abuse-ить. И избавиться от этого изъяна, сохранив систему, невозможно.
но A-z совсем не то-же самое, что и A-Za-z, т.к. включает в себя следующие символы: [ ] ^ _ ` и \ (откройте charmap)
Как минимум это не соответствует regex проверки валидности домена, приведённого выше (где эти символы не включены в разрешённый набор), а как максимум это неверно, т.к. адреса вида name@do\main.ru, name@do[main.ru и name@do]main.ru не валидны.
Я email-ы проверяю такой регуляркой (с ключиком i, поэтому не пишу a-zA-Z):
^(?:[-a-z\d\+\*\/\?!{}`~_%&'=^$#]+(?:\.[-a-z\d\+\*\/\?!{}`~_%&'=^$#]+)*)@(?:[-a-z\d_]+\.){1,60}[a-z]{2,6}$Ссылку страницу со сравнением результатов проверки разных email этой регулярки и регуляркой по rfc822 (вам уже привели этот 6-КБ regex) я не даю, т.к. опасаюсь хабраэффекта :)
P.S. валидация домена тоже «крива».
правда те, кому после вас такие очки достанутся — будут ругаться :)
P.S. у меня тоже после 3D глаза болят, хотя зрение без отклонений и раньше (лет 5 назад) не болели. надо будет для проверки у своих очков «линзы» переставить, благо такие очки у нас по $1 стоят и приходить можно со своими.
мы просто говорим про разные вещи.
предлагаю завязать.
P.S. когда обсуждается, «микроскопом А или микроскопом Б лучше забивать гвозди?», то с бредовым предложением забыть про микроскоп (тип таблиц) и воспользоваться молотком (индексами) в дискуссию лучше не влезать, ибо она тут не к месту.
create index ix_calls_0 on calls (cost, user_id);
а ещё у меня чуть быстрее получилось, если запрос переписать так:
SELECT COUNT(cost) FROM calls INNER JOIN (SELECT id FROM users WHERE sex = 'M') a ON (calls.user_id = a.id) WHERE calls.cost > %d;
последнее ускорило и join MyISAM+MyISAM и InnoDB+InnoDB (извращения типа MyISAM+InnoDB я не проверял)
в таком представлении подобное тестирование имеет смысл для случаев, когда не представляется возможным добавить такие индексы, чтобы join их использовал.
я попытался воспроизвести тест и попробовал добавить индекс на calls.user_id. и от него стало только хуже (глядя на результаты explain становится понятно почему).
однако составной индекс на столбцы user_id + cost решает проблему для данного запроса и он начинает выполняться существенно быстрее (тоже понятно почему). у меня время выполнения запроса с 100% для MyISAM уменьшилось в 40 раз (с ~130 сек до ~3 сек).
т.е. я продолжаю считать, что нужно думать над теми запросами, которые будут выполняться и создавать необходимые индексы, которые будут помогать выполнять запросы (и это касается не только join-ов).
если есть запросы, которые не могут быть оптимизированы добавлением индексов, и при этом данные запросы приводят к полному сканированию таблиц с миллионами записей — самое время вмешиваться в архитектуру.
P.S. ничего против InnoDB я не имею. сказанное мной выше относится и к ним.
Если хочется тестировать скорость JOIN (пусть и сферическую, без индексов, в вакууме), то правильнее было-бы отключить кэширование (опциями в запросе), чтобы тестировать именно скорость JOIN, а не то, какой именно запрос кэшируется и как быстро работает кэш в разных случаях.
и вместо чтения исследований производительности без использования индексов (которое возможно и имеет какой-то сугубо теоретический смысл), новичкам лучше почитать про использование этих самых индексов. этот способ оптимизации гораздо лучшие, чем конвертирование табличек MyISAM <=> InnoDB.
но с моей точки зрения лучше заменить «маргин» на «margin».
а сайты да, они по российским меркам полное дерьмо (особенно в плане дизайна), но блин, они есть у всех гос организаций и у каждого третьего сантехника. и, что касается организаций, они не просто есть для галочки, но они работают и там есть нужная информация.
— через форму обратной связи на сайте города отправляется сообщение о проблеме. там-же сразу указывается, что за проблема: яма, хреново работающий водослив и т.п. как альтернатива — можно позвонить и сообщить об этом по телефону (но просят по телефону беспокоить только в случае серьёзных проблем).
— через несколько дней приедут и посмотрят на месте, что и как (приезжает один человек). ещё через нескольких дней — фиксят (понятно, что сложные случаи фиксятся дольше).
вроде-бы и всё, но… раз в месяц среди сообщивших о проблеме выбирают несколько человек, которым за содействие выдают бабло (кажется $100), типа в знак благодарности за сообщение о проблеме, что мол помог городу :)
P.S. я о проблеме у дома сообщал, приехали и пофиксили быстро (но не полностью, т.к. для полного устранения проблемы надо менять большой водослив), по моему дня за 3. после этого сообщили, что отправили заявку на полное устранение проблемы (типа когда будут водосливы менять где-то в районе — сделают и у нас). но в лотерею не выиграл :)
автор топика немеряно крут.
я проучился в институте (МИЭТ) почти 6 лет и изучал как раз химию и физику изготовления интегральных схем. уже мало что помню, но тем не менее даже у изучаемых тогда 0.1 мкм техпроцессов проблем с дефектами немеряно. и это в промышленных условиях, где доступны большие печи (в них более равномерный нагрев), шлифовальные/полировальные машины в чистых зонах, литографическое оборудование и любые необходимые химикаты высокой степени очистки.
в общей непросто это будет.