Мне вспомнились эти же самые цифры из другого контекста :)
В какой-то книге по садоводству автор писал, что по его наблюдениям, у горе-садоводов-любителей лишь 10% усилий направлены непосредственно на результат, 30% против результата и 60% — на борьбу с теми 30-ю.
Да фтп, фтп…
С год назад была большая волна вируса, который попав в компьютер, сканировал реестр и конфиги на предмет популярных фтп-клиентов и сохраненных в них паролей (FAR, TC и т.п.)
Потом заходил на все доступные сайты и дописывал подобный код ко всем файлам с именами index.php, index.html и т.д.
Тут какая-то разновидность того вируса.
Я немножко изучал рынок themeforest — там публика однозначно предпочитает законченные решения.
То есть чтобы нарисовано, сверстано и в какой-то популярный движок интегрировано. Такие темы, если выглядят симпатично, продаются сотни раз. Просто макеты очень сильно отстают.
Хотя и не без исключений, конечно.
К сожалению, в 11 Опере это уже не работает :-(
В этом и состоит большая проблема Оперы: для неё нет ни одного полностью надежного, предсказуемого хака. Ну, во всяком случае, мне они неизвестны.
У того же IE куча проблем, но он частично реабилитируется, предоставляя множество путей для их решения. А Опера «вещь в себе».
Например, IE иногда любит при обнаружении какой-то ошибки в JS оборвать его выполнение вообще. Соответственно, споткнувшись об одну ошибку (которая может быть вообще в другом месте), JS-функционал может отвалиться вообще весь :)
Поэтому нужно всеми силами избегать завязывать на JS то, что может полностью разрушить макет страницы.
Можно и автоматический пересчет сделать — вообще не вопрос. Я же написал, что это лишь общая канва. Речь о том, что пересчет будет однократным, а не реал-тайм при ресайзе (если компьютер/браузер не из свежих — скорее всего будет тормозить, мерцать при рефреше и т.п.)
Это не неприязнь к jQuery вообще, а нежелание плодить лишние сущности.
Не совсем понял про добавление панели. Сделать так, чтобы например сверху была не одна панель, а две — а средний блок подстраивался бы под их суммарную высоту?
Не вижу никакой проблемы, даже если эта панель будет добавляться на клиенте через JS — нужно будет лишь пересчитать пару отступов (один раз, собственно при добавлении, а не в реальном времени при ресайзе окна). А уж если отдаваться статикой со стороны сервера, тем более.
Подтверждаю.
С немецкой стороны сейчас между экспортом и импортом проходит порядка 12-15 дней. Раньше, в «хорошие» времена, это было 3-7 дней.
Всё это время посылка находится в «вакууме» — у немцев уже не трекается, у нас ещё не трекается.
Мм… нет, при justify последняя строчка не центруется. Она выравнивается влево.
Но вот то, что в ней почти наверняка собьется расстояние между блоками — это да.
Akram, если по ширине — ну тогда наверное вариант с inline-block и пойдет. Только text-align у контейнера сменить на justify. Хотя ручаться не буду, на практике не пробовал.
almazmusic, а «vertical-align: top» разве для inline-block работает? Я не помню точно. Оно точно работает для table-cell, но там будут проблемы со старыми браузерами.
А как нужно, по центру?
Ну можно попытать другой вариант: сделать эти блоки «display: inline-block» и выводить их спложным потоком. А контейнеру-обертке сказать «text-align: center».
Вертикальное расстояние между рядами, наверное, придется регулировать через line-height, вертикальные марджины работать не будут.
Не очень понятно, что значит «не являются текстом и отчасти близки к бинарным», но при этом нужно организовать «полнотекстовый поиск»? Текстовый поиск по не-тексту? Боюсь, без примера данных разговор малопредметен.
О, спасибо — я тоже на днях бился в N++ с заменой. Привычные доллары не работают, а до бэкслеша я как-то не додумался.
Вот каждому нужно сочинить свой диалект регулярок…
Я отписался на их официальном форуме, пока тишина. Гугление выявило несколько похожих тем на англоязычных форумах — судя по ним, проблема тянется минимум с 10-ки. И какого-то решения (не считая костылей типа «удалите лишнее») нигде не видно.
Оно им не надо. Тем более есть подозрение, что проблема не в каком-то баге, концептуальной архитектуре (см. моё уточнение к вопросу). Кто её будет менять? Никто.
Последнее время оперовцы только окошки гламурят, а с основным функционалом типа рендера HTML и работы JS у них всё идёт своим, особенным путём. :)
Проще, наверное, откатиться на старое, благо бэкап сделал.
Монитор обращений к диску показывает, что идет массированное хаотичное (смещения в файлах скачут непредсказуемым образом) чтение из базы сообщений и из «лексикона» очень маленькими блоками (в основном 4-8К, с редкими колебаниями от 1 до 64К). Судя по всему, она читает все 300 тысяч сообщений поштучно, причем в непонятной последовательности! Общее время загрузки базы (теперь засёк) значительно больше часа.
Налицо какой-то дико неоптимальный алогоритм, индусы что ли писали?
В какой-то книге по садоводству автор писал, что по его наблюдениям, у горе-садоводов-любителей лишь 10% усилий направлены непосредственно на результат, 30% против результата и 60% — на борьбу с теми 30-ю.