Математическая логика про массивы ничего не знает, она лишь говорит что при сложении сущностей результатом будет такая же сущность. Это вполне интуитивно, не так ли?
Тут не причем житейская логика.
И да, язык ИМЕЕТ право на то, что массив плюс массив дает строку, но это поведение отличается от ожидаемого.
Он ИМЕЕТ на это право, но если бы он делал это ОЖИДАЕМО — количество бы ошибок УМЕНЬШИЛОСЬ — вот что я имел ввиду.
Ну во-первых складывая два яйца независмо от способа вы получите всетеже два яйца, просто складывая их с силой вы получите два БИТЫХ яйца ) Сущность у Вас не поменялась, поменялось состояние.
Во вторых, логика в программистких языках математическая и никак уж не ассоциируется с обычными языками. В математике говорится — если Вы складываете два слона на выходе вы должны получить ту же сущность. И это одинаково что для математика из Южной Гвинеи, что для Эскимоса, не находите?
По поводу with — его убрали из-за неочивидности поведения, да им можно было кое-что и полезное делать, но ИМХО — правильно что убрали. Хотите скоп — вводите скоп, а не странную функцию с неоднозначным поведением. Ошибок можно было наплодить с ним, даже зная все его особенности.
Не согласен с Вами — язык должен ориентироваться на обычную логику человека, и дела не втом, что должен программист, а что не должен.
Программист — прежде всего — человек.
Можно и define true false сделать — и описать это в стандарте языка — это не протеворечит ничему.
НО! Это противоречит ожидаемому поведению — отсюда — буду возникать ошибки.
Хороший язык с моей точки зрения:
1) ведет ожидаемо с точки зрения человека, ибо написан он прежде всего для него
2) ограничивает возможность совершить ошибку
Отрекшись от знаний JS подумайте просто чисто из ощущений — если вы складываете два массива что вы должны получить? cтроку?
Язык должен помогать человеку, ведь он для него и написан.
Мне очень нравится JS и он все больше стремится к идеальному языку, и надеюсь эти грабли в конце концов уберут как было с with
Ну, если у Вас на фирме программисты — роботы — это конечно хорошо — Вы получаете четкий стандартный код и всегда можете точно спрогнозировать сроки — круто!
Но есть одно но — я считаю, что не стоит путать ПРОГРАММИСТА и КОДЕРА, это разные, абсолютно разные веши — примерно как художник и копировальный аппарат :-D
Так вот про кодеров Все что Вы написали — абсолютная правда, а программист — это гораздо больше. Это Кодер + Творчество как раз.
Плохо это или хорошо — не знаю. Можно быть хорошим кодером — и это хорошо, но, ИМХО, грустно :-D
Оптимизация, та, которую я сказал нужна вне зависимости от сервера — ибо она при любом фронтенеде ускоряет загрузку. И вопрос не в сервере, вопрос именно в методах. Тут не причем ни Апач ни лайт.
Или вы считаете что если сайт не хайлоад, то пусть и волочит якорь и оптимизировать его не надо? Однако пользоввателю есть разница — загрузится страница за 3 секунды или за одну, даже если таких пользователей на Вашем сайте всего 50 ;)
я понял что Вы имели ввиду :) Просто не люблю когда рубят с плеча.
И если для проекта можно обойтись lighthttpd & nginx + у вас есть хостинг позвоялющий это — то да — есть на это резон, но вот говорить так агульно «надо отказаться от апач», это, извините, смешно.
Вообще есть правило хорошее «Ко всему подхродить с умом» :-D
А по поводу lighthttpd & nginx можно ведь почитать ПОЧЕМУ они так быстро работают :)
Я даже отвечу на вопрос — они ЗАТОЧЕНЫ под конкретное действо, а Апач — универсален.
Поэтому пытаться их сравнивать — не совсем корректно а говрить что nginx круче чем Апач тем более.
Усложнится совсем на чуть чуть но это даст возможность работаь с сайтом и без nginx — более высока я переносимость, хотя если в этом нет необходимости — то и смысла делать нет.
Я полностью согласен с Вашим методом.
minify каждый раз отдет статику через себя, т.е. его надо к кэшу пркручивать, но как Вариант — вполне.
Мне не очень понравился потому как у меня в движке еще масса всего делается при формировании кэша статики да и процесс хотелось бы контролировать. Кроме того по поводу минификации YUI или же Closure Compiller жмет гораздо лучше.
Согласен. Там действительно проще это сделать.
Однако насчет «не будет эффекта» — не соглашусь — если Апач у Вас ОДИН раз подготовит статику в определнном месте, а потом из этого места ее отдает nginx — ничего в плане быстродействия Вы не потеряете.
ob_gzhandler к сожелению ориентируется только на основании заголовка Accept-Encoding, об этом тоже в хелпе есть. Увы и ах — этого не всегда достаточно, например для конкуер (а также IE5/IE6).
Про nginx — господа, если на фронтэнде у Вас торчит nginx — это круто, действительно круто, но во-первых вся эта методика подходит и для него, во вторых обычно бэкэнд у него — Апач.
По этому не очень уместно спорить здесь в ключе «Камаз конечно хорошо, но вот бэха! Бэха гораааздо круче» :)
Обычно nginx есть у VDS а не у простых хостингов, а VDS — совсем другая песня — я про это упоминалу уже )
Про YUI & Google Closure — естественно JS как и CSS надо оптимизировать через них (я например использую YUI)
Но здесь я рассказывал немного не об этом, не так ли? Можно было конечно и упомянуть минимизацию, но я считаю чтобы не было сумятицы — котлеты отдельно, мухи отельно.
Минимайзеры — это вообще тема для отедльной статьи.
Так, и вот самое интересное — для меня очень интересное, как господа у которых сборка проекта осуществляется через запуск спец скриптов (например через шелл).
Как применить тотже YUI или другие утилиты — это вполне понятно, непонятно одно — как Вы определяете КАКИЕ файлы для КАКОЙ странички склеивать?
Т.е. во-первых как у Вас подключаются склеиваемые скрипты на страничках, во вторых, как вы узнаете для каокй страницы какие скрипты склеивать?
У меня сделать это както хорошо, чтобы не мозолило глаза — увы — не получилось. Поделитесь опытом? Буду очень признателен.
Вот такой метод мне как раз не нравится… хотя бы тем, что в описанном здесь случае чтобы сделать из ветки дев ветку продакшен достаточно просто поменять одну константу :)
Тут не причем житейская логика.
И да, язык ИМЕЕТ право на то, что массив плюс массив дает строку, но это поведение отличается от ожидаемого.
Он ИМЕЕТ на это право, но если бы он делал это ОЖИДАЕМО — количество бы ошибок УМЕНЬШИЛОСЬ — вот что я имел ввиду.
Во вторых, логика в программистких языках математическая и никак уж не ассоциируется с обычными языками. В математике говорится — если Вы складываете два слона на выходе вы должны получить ту же сущность. И это одинаково что для математика из Южной Гвинеи, что для Эскимоса, не находите?
По поводу with — его убрали из-за неочивидности поведения, да им можно было кое-что и полезное делать, но ИМХО — правильно что убрали. Хотите скоп — вводите скоп, а не странную функцию с неоднозначным поведением. Ошибок можно было наплодить с ним, даже зная все его особенности.
Программист — прежде всего — человек.
Можно и define true false сделать — и описать это в стандарте языка — это не протеворечит ничему.
НО! Это противоречит ожидаемому поведению — отсюда — буду возникать ошибки.
Хороший язык с моей точки зрения:
1) ведет ожидаемо с точки зрения человека, ибо написан он прежде всего для него
2) ограничивает возможность совершить ошибку
Отрекшись от знаний JS подумайте просто чисто из ощущений — если вы складываете два массива что вы должны получить? cтроку?
Язык должен помогать человеку, ведь он для него и написан.
Мне очень нравится JS и он все больше стремится к идеальному языку, и надеюсь эти грабли в конце концов уберут как было с with
Как и кодеру — поганый )
Ну, если у Вас на фирме программисты — роботы — это конечно хорошо — Вы получаете четкий стандартный код и всегда можете точно спрогнозировать сроки — круто!
Но есть одно но — я считаю, что не стоит путать ПРОГРАММИСТА и КОДЕРА, это разные, абсолютно разные веши — примерно как художник и копировальный аппарат :-D
Так вот про кодеров Все что Вы написали — абсолютная правда, а программист — это гораздо больше. Это Кодер + Творчество как раз.
Плохо это или хорошо — не знаю. Можно быть хорошим кодером — и это хорошо, но, ИМХО, грустно :-D
Я ниже отписался HnH по этому поводу.
Или вы считаете что если сайт не хайлоад, то пусть и волочит якорь и оптимизировать его не надо? Однако пользоввателю есть разница — загрузится страница за 3 секунды или за одну, даже если таких пользователей на Вашем сайте всего 50 ;)
я понял что Вы имели ввиду :) Просто не люблю когда рубят с плеча.
И если для проекта можно обойтись lighthttpd & nginx + у вас есть хостинг позвоялющий это — то да — есть на это резон, но вот говорить так агульно «надо отказаться от апач», это, извините, смешно.
А по поводу lighthttpd & nginx можно ведь почитать ПОЧЕМУ они так быстро работают :)
Я даже отвечу на вопрос — они ЗАТОЧЕНЫ под конкретное действо, а Апач — универсален.
Поэтому пытаться их сравнивать — не совсем корректно а говрить что nginx круче чем Апач тем более.
Самолет круче машины? ;)
Я полностью согласен с Вашим методом.
Мне не очень понравился потому как у меня в движке еще масса всего делается при формировании кэша статики да и процесс хотелось бы контролировать. Кроме того по поводу минификации YUI или же Closure Compiller жмет гораздо лучше.
Однако насчет «не будет эффекта» — не соглашусь — если Апач у Вас ОДИН раз подготовит статику в определнном месте, а потом из этого места ее отдает nginx — ничего в плане быстродействия Вы не потеряете.
А по поводу подключения к index.html — окей, а к другим страницам сайта? Или у Вас все скрипты всегда подключаются ко всем страницам?
Про nginx — господа, если на фронтэнде у Вас торчит nginx — это круто, действительно круто, но во-первых вся эта методика подходит и для него, во вторых обычно бэкэнд у него — Апач.
По этому не очень уместно спорить здесь в ключе «Камаз конечно хорошо, но вот бэха! Бэха гораааздо круче» :)
Обычно nginx есть у VDS а не у простых хостингов, а VDS — совсем другая песня — я про это упоминалу уже )
Про YUI & Google Closure — естественно JS как и CSS надо оптимизировать через них (я например использую YUI)
Но здесь я рассказывал немного не об этом, не так ли? Можно было конечно и упомянуть минимизацию, но я считаю чтобы не было сумятицы — котлеты отдельно, мухи отельно.
Минимайзеры — это вообще тема для отедльной статьи.
Так, и вот самое интересное — для меня очень интересное, как господа у которых сборка проекта осуществляется через запуск спец скриптов (например через шелл).
Как применить тотже YUI или другие утилиты — это вполне понятно, непонятно одно — как Вы определяете КАКИЕ файлы для КАКОЙ странички склеивать?
Т.е. во-первых как у Вас подключаются склеиваемые скрипты на страничках, во вторых, как вы узнаете для каокй страницы какие скрипты склеивать?
У меня сделать это както хорошо, чтобы не мозолило глаза — увы — не получилось. Поделитесь опытом? Буду очень признателен.