Pull to refresh
30
0
Максим @pro100tak

User

Send message
Tools -> Analyze Xdebug Profiler Snapshot позволяет построить дерево callee/caller с указанием времени выполнения и места в коде.

П.С. Сам по себе формат трейса простейший и я справлялся консолью (например, cat trace.xt | grep mysql и т.д.)

П.П.С. Но вы молодец, хоть можно потыкать мышкой
PHPStorm:
Tools -> Analyze Stacktrace.
Tools -> Analyze Xdebug Profiler Snapshot
Нет обоснования, это моё мнение. Миллиарды загрузок jQuery с Google CDN по всему миру — и я не слышал ни разу о факте недоставки контента.
Конкатенацию файлов надо бы применять умно: конкатенировать группы файлов. Сначала те, которые важны для первоначальной загрузки страницы и загрузки остальных файлов, потом уже группа(-ы) второстепенных файлов.
Также, все популярные библиотеки и так закешированы и Google CDN наверняка быстрее и отказоустойчивее чем Akamai
1. К сожалению, код протестировать без артефактов на диске не получится.
2. У Excel немного больше форматов, чем «строка», «число», «дата». Например, форматированные проценты, дроби с конфигурируемым количеством знаков после запятой.
3. Форматирование ячейки (не путать с форматом!) тут не учитывается тоже.

П.С. Я так понимаю, автор делал сей код для простенького упаковщика, но с таким же успехом можно было использовать fputcsv(...)

П.П.С. Я нисколько не умаляю заслуг ТС! Написал и поделился — молодец! Даёшь качественные пулл-реквесты!
Нифига себе. Это ж получается е-сигара. Е-Cohiba Behike
Это наиболее информационно ёмкий комментарий на весй странице включая сухой рекламный текст
Так на андроиде же можно настроить шаблоны сообщений и спокойно отправлять нужные. Правда, я не знаю как насчёт хэнгаута…
И то правда… Ок, откидываем как нерабочее :)
Сорри, вначале неправильно (в коде — правильно).
ORDER BY path, LENGTH(path)
Эммм. ORDER BY LENGTH(path), path…

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; 
-- Всё гут


Может будут тратится ресурсы на подсчёт длины строки, но не такие существенные, как коверкание пути. Он ведь служит для наглядности
Можно же расширить дырку на бампере чтобы большой разъём прилегал нормально. Я так и делал.
Проще новый купить :)
Кстати, 80% результатов первой страницы гугла по запросу «php localization» толкуют таки о gettext.
Все описанные проблемы по случайному стечению обстоятельств решены в gettext. Программа PO-edit. Она есть практически стандарт у переводчиков и не вызывает отторжения если я им даю английский файл (творческие люди, что с них взять :)). РО-edit прекрасно показывает непереведённые строки, строки с приблизительным переводом, умеет работать со множественными числами и т.д.

Распространение файлов переводов — задача системы доставки кода, которая наверняка уже есть в проекте.
Версионность — добро пожаловать в системы контроля версий. Новый коммит — новая версия. Тут всё просто.
Ngettext — множественные числа напрямую встроенные в модуль.
Моих переводчиков не пугали подстановки sprintf(), их спокойно можно использовать в тексте переводов.

На самом деле — мы ушли от темы. Не в gettext дело. Дело в том, что вы путаете данные (контент) и систему хранения контента (БД) с интерфейсом. Если какие- то менюшки, переводы, разметка хранятся в БД, чтож, пусть, но пусть это будет ДРУГАЯ БД. Подключенная в read-only в амазоне чтобы уменьшить время сборки страницы и при отказах не показывать пустой экран.

Засим дискуссию считаю законченной, спасибо за внимание.
Причем тут это вообще не понятно. Любая система локализации никак не влияет на масштабирование.

Айяйяй. Я не уверен в этом. Даже джойн джойну рознь и может утопить СУБД. В данном случае — это попросту растрата ценного ресурса.

Ну так поясните нам, о каких нагрузках вы рассуждаете, а то знаете ли ORM и ООП — тоже могут быть «архитектурными просчетами».

Сколько экспрессии! Каков драматизм!
Ответ см. выше. Кроме абстракного 3+ посетителя — цифр приведено не было :) Как я смогу вам объяснить, что да. в некоторых условиях квадратные колёса поедут вполне комфортно, но для этого придётся готовить покрытие.
А зачем? Gettext их и так закеширует в памяти. Абсолютно прозрачно, без ещё одного слоя абстракции для кеша, без ещё одной внешней зависимости.
Я не адепт gettext, он просто пример. Я просто против совмещения интерфейса и данных. Все велосипеды придуманы и вам остаётся только складывать кирпичики в правильной последовательности. а не добывать глину, строить печь для обжига, выдерживать их и т.д.
Кстати, переводы надо не только хранить, но и поддерживать, дать удобный инструмент для переводчиков, задумываться о версионности, придумывать систему распространения переводов по узлам системы.

Отговорка: это не касается перевода данных (т.е. статей, постов, документации или любого другого контента)
Переводы должны храниться в БД, а не файлах.

Категорическое нет. Для переводов (локализации) и интернационализации придумали миллион подходов. Самый простой для понимаия — локали и gettext, который ложится в память и практически не влияет на скорость генерации локализованной страницы.
Запомните одно простое правило — интерфейс != данные. Смешивать их даже на уровне системы хранения попросту чревато. Или у вас никогда не отваливалась БД? А так — показали холодные данные из кеша (пусть и немного прокисшие) даже при отсутствии живого соединения с базой, но в переведённом интерфейсе.

Хотя, для сайтишек на 3 калеки в час — сойдёт. Если больше — надо думать не столько о наполнении, сколько о живучести и задавать себе преинтереснейшие вопросы: а что будет если выключить CDN; а что будет, если завтра добавится новый backend; а сможет ли проект без переписывания масштабироваться горизонтально? И вот тогда наружу проступают эти изначальные архитектурные просчёты.
Snipping tool или Ножницы в русской винде.

Information

Rating
Does not participate
Location
Харьков, Харьковская обл., Украина
Date of birth
Registered
Activity