Я не совсем об этом — склеить и пожать файлы это не проблема. Когда известно какие именно надо клеить и жать. А вот отследить все зависимости в большом проекте, значительно сложнее. Для разных частей сайта нужно делать разные «пакеты» JS.
Или делайте просто один большой универсальный JS файл?
Согласен с вами. Гораздо дешевле отдавать статитку, чем какждый раз генерить файл (пусть даже с учетом кеша)
А можете какую ни будь софтину что которая бы помогла это? понятно что можно написать скрипт который делал бы это при деплои. Но может быть есть уже чтото готовое, что могло бы облегчить этот нудный труд?
1) Вы правы но есть же ОС где, aststone capture не работает :) А мне вот такое расширение очень пригодилось!
2) Опять же это акутально если используется больше чем 1 браузер
Сижу под openSuse. Сам вебразработчик, правда больше серверсайд. Очень долго сидел но Фоксе и нежно его люблю. Но давайте честно — тормозит зараза просто зверски. Может под виндой FF работает быстрее, но в линксе Хром стал для меня просто глотком свжего воздуха — намного приятней и комфортней стало работать в инете.
Поставил себе Xmarks и на хром и на фокс и к фоксу возвращаюсь когда нужные его спецефеские расширение, коих еще ой как много.
Так что от всей души желаю FF побольше юзеров и разработчиков, но пока разница в скорости настлько сильно ощутима, просто вынужден сидеть на хроме большую часть времени :( Хотя Firefox у меня всегда будет masthave еще очень очень долго — расширения наше все! :)
Да, я именно про внутрение устройство. На прошлом хайлоаде был интересный доклад, но опять же это для тех кто уже в теме. А вот что бы сесть и с нуля написать модуль — сложнее. Но думаю со временем будут и такие доки.
Плюсую вас и плачу! :) Да это большая беда VLC — вроде как не умеет. Доходит до смешного — качаю видео в OpenSUSE на мощном компе, а смотреть приходится в нетбуке изза CoreAVC Pro. Печально…
Люблю VLC как проигрыватель — только его и использую на всех системах. Просто восторг!
Но вот фраза
> обладая дружелюбным и простым пользовательским интерфейсом
немного настораживает… :) Мне кажется интерфейс это не самая сильная сторона VLC… мягко говоря :)
Но желаю удачи ребятам — когда допилят, наверняка получится функциональный инструмент, которым я бы с радостью буду пользоваться.
Было бы интересно узнать, что Майкл думает о Drizzle? Стоило ли делать форк или можно было бы попытаться как то сделать сам MySQL боле модульныс, с разными вариантами сборки?
PS Продукт уже достаточно известен, но если кто не в курсе, то Drizzle и пару видео докладов есть тут
Не поспоришь :) Но настройки которые меняет юзер, надо же гдето хранить. Конечно можно в XML сохранять… Но как то не хочется с ним связываться. Лучше уже потерплю несовершенство мира и буду считать что дефолтовое подключение к БД уже есть. :)
Я не совсем соглашусь — при большой нагрузке вопрос становится актуальным.
Случай из практики — по недосмотру, не включили на продакшене кеширование конфигов. Так в час пик сервер чуть не помер, пытаясь считать из FS файл с конфигамми для каждого запроса…
Было бы интересно, как автор решает проблему настроек которые должен менять админ сайта? Гонять клиента менять файлы — несколько не кузяво. Пользователю удобней использовать GUI.
С другой стороны — разработчику проще работать с конфиг файлами и использовать везде чтото вроде Config::get('key').
В идеале, должно быть два уровня конфигов — первый это файлы которые меняют разработчики. Второй, настройки которые юзер задает из GUI.
Если одни и тот же ключ встречается в обоих слоях — уровень юзера побеждает. То есть если в конфиге 'blog.post_per_page' = 10
a юзер в GUI поставил 20, то для кода
'blog.post_per_page' = 20
Собственно я к чему — не видел ли кто ни будь уже готовой реализации такой идеи?
Вам не кажется что, для реализации кода отрисовки бокса на странице вполне подходит патерн
Strategy? И конечно при его реализации, мне где ни будь да заюзаем include…
Но есть все же большая разница как именно мы используем include — как побочный инструмент (в моем случае) или как основной (в варианте топикастера).
Ни чего не мешает, вы правы. Я вообще не религиозен в плане кода. Если чтото работает и это возможно поддерживать — почему бы не использовать. :)
Но я скорее хотел увидеть от вас плюсы подключения конфигов таким образом, чем спорить и доказывать что я прав :) Знания новых подходов и чужой опыт для меня ценнее абстрактной правоты.
Или делайте просто один большой универсальный JS файл?
А можете какую ни будь софтину что которая бы помогла это? понятно что можно написать скрипт который делал бы это при деплои. Но может быть есть уже чтото готовое, что могло бы облегчить этот нудный труд?
2) Опять же это акутально если используется больше чем 1 браузер
Поставил себе Xmarks и на хром и на фокс и к фоксу возвращаюсь когда нужные его спецефеские расширение, коих еще ой как много.
Так что от всей души желаю FF побольше юзеров и разработчиков, но пока разница в скорости настлько сильно ощутима, просто вынужден сидеть на хроме большую часть времени :( Хотя Firefox у меня всегда будет masthave еще очень очень долго — расширения наше все! :)
Но вот фраза
> обладая дружелюбным и простым пользовательским интерфейсом
немного настораживает… :) Мне кажется интерфейс это не самая сильная сторона VLC… мягко говоря :)
Но желаю удачи ребятам — когда допилят, наверняка получится функциональный инструмент, которым я бы с радостью буду пользоваться.
PS Продукт уже достаточно известен, но если кто не в курсе, то Drizzle и пару видео докладов есть тут
Случай из практики — по недосмотру, не включили на продакшене кеширование конфигов. Так в час пик сервер чуть не помер, пытаясь считать из FS файл с конфигамми для каждого запроса…
собственно, имхо, самое сложное тут генерация GUI для юзера. :)
Я просто думал может где то в недрах Zend илл Pear есть чтото подобное, что бы пилить свой велосипед уже на пустом месте :)
Было бы интересно, как автор решает проблему настроек которые должен менять админ сайта? Гонять клиента менять файлы — несколько не кузяво. Пользователю удобней использовать GUI.
С другой стороны — разработчику проще работать с конфиг файлами и использовать везде чтото вроде Config::get('key').
В идеале, должно быть два уровня конфигов — первый это файлы которые меняют разработчики. Второй, настройки которые юзер задает из GUI.
Если одни и тот же ключ встречается в обоих слоях — уровень юзера побеждает. То есть если в конфиге 'blog.post_per_page' = 10
a юзер в GUI поставил 20, то для кода
'blog.post_per_page' = 20
Собственно я к чему — не видел ли кто ни будь уже готовой реализации такой идеи?
Пойду учиться писать без богомерзких патернов.
unserialize(file_get_contents($file))
Точно так же хранит конфиги Kohana — теперь понятно почему.
Да, думаю ваша статья будет интересной — особенно для высоких нагрузок.
Думается мне что если сделать,
unserialize(apc_fetch($config_key))
то будет еще быстрее. Хотя не принципиально — файловый кеш еще ни кто не отменял.
Вам не кажется что, для реализации кода отрисовки бокса на странице вполне подходит патерн
Strategy? И конечно при его реализации, мне где ни будь да заюзаем include…
Но есть все же большая разница как именно мы используем include — как побочный инструмент (в моем случае) или как основной (в варианте топикастера).
Но я скорее хотел увидеть от вас плюсы подключения конфигов таким образом, чем спорить и доказывать что я прав :) Знания новых подходов и чужой опыт для меня ценнее абстрактной правоты.