Конкатенацию файлов надо бы применять умно: конкатенировать группы файлов. Сначала те, которые важны для первоначальной загрузки страницы и загрузки остальных файлов, потом уже группа(-ы) второстепенных файлов.
Также, все популярные библиотеки и так закешированы и Google CDN наверняка быстрее и отказоустойчивее чем Akamai
1. К сожалению, код протестировать без артефактов на диске не получится.
2. У Excel немного больше форматов, чем «строка», «число», «дата». Например, форматированные проценты, дроби с конфигурируемым количеством знаков после запятой.
3. Форматирование ячейки (не путать с форматом!) тут не учитывается тоже.
П.С. Я так понимаю, автор делал сей код для простенького упаковщика, но с таким же успехом можно было использовать fputcsv(...)
П.П.С. Я нисколько не умаляю заслуг ТС! Написал и поделился — молодец! Даёшь качественные пулл-реквесты!
INSERT INTO test (path) VALUES ('1'), ('2'), ('3'), ('1.1'), ('1.2'), ('1.10'), ('1.10.1'), ('1.10.2'), ('1.3');
SELECT * FROM test LIMIT 0, 1000;
-- 1.3 внизу как и ожидалось
SELECT * FROM test ORDER BY path, LENGTH(path) LIMIT 0, 1000;
-- Всё гут
Может будут тратится ресурсы на подсчёт длины строки, но не такие существенные, как коверкание пути. Он ведь служит для наглядности
Все описанные проблемы по случайному стечению обстоятельств решены в gettext. Программа PO-edit. Она есть практически стандарт у переводчиков и не вызывает отторжения если я им даю английский файл (творческие люди, что с них взять :)). РО-edit прекрасно показывает непереведённые строки, строки с приблизительным переводом, умеет работать со множественными числами и т.д.
Распространение файлов переводов — задача системы доставки кода, которая наверняка уже есть в проекте.
Версионность — добро пожаловать в системы контроля версий. Новый коммит — новая версия. Тут всё просто.
Ngettext — множественные числа напрямую встроенные в модуль.
Моих переводчиков не пугали подстановки sprintf(), их спокойно можно использовать в тексте переводов.
На самом деле — мы ушли от темы. Не в gettext дело. Дело в том, что вы путаете данные (контент) и систему хранения контента (БД) с интерфейсом. Если какие- то менюшки, переводы, разметка хранятся в БД, чтож, пусть, но пусть это будет ДРУГАЯ БД. Подключенная в read-only в амазоне чтобы уменьшить время сборки страницы и при отказах не показывать пустой экран.
Засим дискуссию считаю законченной, спасибо за внимание.
Причем тут это вообще не понятно. Любая система локализации никак не влияет на масштабирование.
Айяйяй. Я не уверен в этом. Даже джойн джойну рознь и может утопить СУБД. В данном случае — это попросту растрата ценного ресурса.
Ну так поясните нам, о каких нагрузках вы рассуждаете, а то знаете ли ORM и ООП — тоже могут быть «архитектурными просчетами».
Сколько экспрессии! Каков драматизм!
Ответ см. выше. Кроме абстракного 3+ посетителя — цифр приведено не было :) Как я смогу вам объяснить, что да. в некоторых условиях квадратные колёса поедут вполне комфортно, но для этого придётся готовить покрытие.
А зачем? Gettext их и так закеширует в памяти. Абсолютно прозрачно, без ещё одного слоя абстракции для кеша, без ещё одной внешней зависимости.
Я не адепт gettext, он просто пример. Я просто против совмещения интерфейса и данных. Все велосипеды придуманы и вам остаётся только складывать кирпичики в правильной последовательности. а не добывать глину, строить печь для обжига, выдерживать их и т.д.
Кстати, переводы надо не только хранить, но и поддерживать, дать удобный инструмент для переводчиков, задумываться о версионности, придумывать систему распространения переводов по узлам системы.
Отговорка: это не касается перевода данных (т.е. статей, постов, документации или любого другого контента)
Категорическое нет. Для переводов (локализации) и интернационализации придумали миллион подходов. Самый простой для понимаия — локали и gettext, который ложится в память и практически не влияет на скорость генерации локализованной страницы.
Запомните одно простое правило — интерфейс != данные. Смешивать их даже на уровне системы хранения попросту чревато. Или у вас никогда не отваливалась БД? А так — показали холодные данные из кеша (пусть и немного прокисшие) даже при отсутствии живого соединения с базой, но в переведённом интерфейсе.
Хотя, для сайтишек на 3 калеки в час — сойдёт. Если больше — надо думать не столько о наполнении, сколько о живучести и задавать себе преинтереснейшие вопросы: а что будет если выключить CDN; а что будет, если завтра добавится новый backend; а сможет ли проект без переписывания масштабироваться горизонтально? И вот тогда наружу проступают эти изначальные архитектурные просчёты.
П.С. Сам по себе формат трейса простейший и я справлялся консолью (например, cat trace.xt | grep mysql и т.д.)
П.П.С. Но вы молодец, хоть можно потыкать мышкой
Tools -> Analyze Stacktrace.
Tools -> Analyze Xdebug Profiler Snapshot
Также, все популярные библиотеки и так закешированы и Google CDN наверняка быстрее и отказоустойчивее чем Akamai
2. У Excel немного больше форматов, чем «строка», «число», «дата». Например, форматированные проценты, дроби с конфигурируемым количеством знаков после запятой.
3. Форматирование ячейки (не путать с форматом!) тут не учитывается тоже.
П.С. Я так понимаю, автор делал сей код для простенького упаковщика, но с таким же успехом можно было использовать fputcsv(...)
П.П.С. Я нисколько не умаляю заслуг ТС! Написал и поделился — молодец! Даёшь качественные пулл-реквесты!
ORDER BY path, LENGTH(path)
Может будут тратится ресурсы на подсчёт длины строки, но не такие существенные, как коверкание пути. Он ведь служит для наглядности
Распространение файлов переводов — задача системы доставки кода, которая наверняка уже есть в проекте.
Версионность — добро пожаловать в системы контроля версий. Новый коммит — новая версия. Тут всё просто.
Ngettext — множественные числа напрямую встроенные в модуль.
Моих переводчиков не пугали подстановки sprintf(), их спокойно можно использовать в тексте переводов.
На самом деле — мы ушли от темы. Не в gettext дело. Дело в том, что вы путаете данные (контент) и систему хранения контента (БД) с интерфейсом. Если какие- то менюшки, переводы, разметка хранятся в БД, чтож, пусть, но пусть это будет ДРУГАЯ БД. Подключенная в read-only в амазоне чтобы уменьшить время сборки страницы и при отказах не показывать пустой экран.
Засим дискуссию считаю законченной, спасибо за внимание.
Айяйяй. Я не уверен в этом. Даже джойн джойну рознь и может утопить СУБД. В данном случае — это попросту растрата ценного ресурса.
Сколько экспрессии! Каков драматизм!
Ответ см. выше. Кроме абстракного 3+ посетителя — цифр приведено не было :) Как я смогу вам объяснить, что да. в некоторых условиях квадратные колёса поедут вполне комфортно, но для этого придётся готовить покрытие.
Я не адепт gettext, он просто пример. Я просто против совмещения интерфейса и данных. Все велосипеды придуманы и вам остаётся только складывать кирпичики в правильной последовательности. а не добывать глину, строить печь для обжига, выдерживать их и т.д.
Кстати, переводы надо не только хранить, но и поддерживать, дать удобный инструмент для переводчиков, задумываться о версионности, придумывать систему распространения переводов по узлам системы.
Отговорка: это не касается перевода данных (т.е. статей, постов, документации или любого другого контента)
Категорическое нет. Для переводов (локализации) и интернационализации придумали миллион подходов. Самый простой для понимаия — локали и gettext, который ложится в память и практически не влияет на скорость генерации локализованной страницы.
Запомните одно простое правило — интерфейс != данные. Смешивать их даже на уровне системы хранения попросту чревато. Или у вас никогда не отваливалась БД? А так — показали холодные данные из кеша (пусть и немного прокисшие) даже при отсутствии живого соединения с базой, но в переведённом интерфейсе.
Хотя, для сайтишек на 3 калеки в час — сойдёт. Если больше — надо думать не столько о наполнении, сколько о живучести и задавать себе преинтереснейшие вопросы: а что будет если выключить CDN; а что будет, если завтра добавится новый backend; а сможет ли проект без переписывания масштабироваться горизонтально? И вот тогда наружу проступают эти изначальные архитектурные просчёты.