Shaarli - асоциальный Delicious

- Posted in Uncategorized by

https://github.com/sebsauvage/Shaarli

Shaarli - The personal, minimalist, super-fast, no-database delicious clone. By sebsauvage.net. Shaarli is a minimalist delicious clone you can install on your own website. It is designed to be personal (single-user), fast and handy.

В общем, для тех, кому нравится идея Делишеса как быстрого сборника ссылок с заметками, но при этом совершенно не интересует его социальная составляющая -- на первый взгляд вполне себе вариант. Вблизи ещё "будем посмотреть", только что обнаружил. Может кто знает плюсоминусы и готов посоветовать что-то более удобное/надежное - you are welcome.

Нынешний делишес меня задалбывает периодическими отказами (в самый неподходящий момент вдруг не могу букмарклетом добавить ссылку), неполным бекапом, очень сильно тормозящим новым сайтом (превед, обильные JS c AJAX-ами, я вас ненавижу). Да и неудобный этот их новый сайт. Ещё и RSS нет. И как они предлагают следить за интересующими обновлениями? На сайт заходить? Как фейсбук? Странные люди. Ни туда, ни туда я в итоге вообще не захожу.

В локальную вики сохранять - вариант, пользуюсь единым хранилищем. Это по-прежнему WikidPаd. Но сейчас иногда экспериментирую (WikidPad тяжеловесен и чаще я не его запускаю, а текстовым редактором быстро в вики-файлах ковыряюсь - и для добавлений, и для поисков) и предпочитаю линки дублировать в оба места: как в делишес, так и в вики. Потому что помнятся ещё времена, когда делишесом несколько человек с пересекающимися интересами пользовались, и это приносило свои плоды.

И мне ещё очень хочется в WikidPad-е поддержку Markdown, а её готовой нет. А мне не настолько хочется, чтобы всё бросать и этой задачкой заниматься. Поэтому иногда появляются мысли сбежать к `gitit` или ZimWiki, как вариант. ZimWiki, конечно, странный вариант для миграции с WikidPad на него, но чем чёрт не шутит? Пользуюсь иногда для мелких вики по проектам, думаю пока.

UPD 2013-04-28. У Делишеса заработал экспорт (пару дней был недоступен), забрал все ссылки, импортировал в Shaarli. Кстати, ровная юбилейная цифра получилась: 4000 links у меня сейчас. 1265 тегов в tag cloud.

  • Полёт нормальный, никаких тормозов.
  • Файл со всеми закладками теперь 600k вместо 3k.
  • Делишесом последние несколько дней я вообще не смог пользоваться: после загрузки страницы её даже листать скроллером -- большая проблема. В общем, не понимаю я ни их верстальщика, ни вектора развития.

Прощай, Делишес.

Кстати, по поводу цифр и объёмов: пользоваться Делишесом я начал в декабре 2005. Так что в среднем где-то 571 линк в году: пара линков в день.

UPD2: лёгкие тормоза ощущаются только при автоподсказке вводимых тегов. Но это отключаемо при желании, насколько помню настройки. Я лично хорошо помню свои теги и ассоциации, поэтому быстрее их ввожу, подсказки чисто декоративную роль играют.

UPD3: ах, да: http://rb.labtodo.com/links/.

UPD 2013-07-01. Несколько напрягает способ хранения ссылок: в одну строку и зашифровано. Внутри там массив кажется (деталей не помню), но в файле хранится в зашифрованном виде в целях безопасности: чтобы даже в случае упёртого файла ваши линки остались вашими. Но я не знаю, кому как, а у меня приватных линков там -- всего 220 из более чем 4 тысяч (4221), и это с 2005 года. В которые повторно почти и не заглядываю никогда, как практика показывает. Так что половина из них уже скорей всего устарела. Кому нужны эти "секреты"?

Все линки хранятся в одном файле, а внтури этого файла - в виде одной строки. 685 килобайт. Длина одной строки. В день в среднем добавляется пару ссылок. Большая часть из которых редактируется несколько раз, т.к. Shaarli удобно использовать как микроблог и записную книжку. Как я уже сказал чуть выше - меня эта строка длиной в полмегабайта всё больше беспокоит. Предпочёл бы что-то более более распределенное по файловой системе. Во избежание.

Это ещё одна причина, которая рано или поздно всё же заставит меня пристальней смотреть в сторону альтернатив: поддержка нескольких пользователей, плюс более гуманные способы работы/хранения при больших количествах закладок.

Opencart: генераторы sitemap.xml (Google Sitemap) и YML (Yandex.Market) для большого количества товаров

- Posted in Uncategorized by

Решения, рассчитанные на большое количество товаров:

Сам я ни одно из этих решений не проверял на больших количествах товаров. Воспринимайте как список для справки, изучения и обсуждения.

Главные проблемы стандартного генератора sitemap.xml, в котором по традиции всё делается в лоб и без оптимизаций:

  • из базы выбираются сразу все товары. На этом этапе при большом их количестве проблемы могут возникнуть как у сервера баз данных, так и с местом на временном разделе;
  • всё это передаётся PHP и в памяти формируется одна большая строка, содержащая весь XML. Только в конце она записывается в файл. На этом шаге тоже вполне можно упереться в ограничение доступной памяти;
  • а заодно можно легко упереться и в ограничение на время выполнения скрипта (по умолчанию обычно 30 секунд). И некоторые хостинги запрещают это время увеличивать (как раз для борьбы с ресурсоемкими и неоптимизированными скриптами). Впрочем, вряд ли магазин со 100 тысячами товаров будет пользоваться шаред хостингом. Но проблемы возникают и на более мелких количествах - порядка 20-30 тысяч. Хотя может даже и раньше (см. пост Yoda в блоге, первая ссылка - там речь о том, что уже и на 3000 бывают проблемы на некоторых серверах);
  • у гугла есть какие-то ограничения на размер файла sitemap.xml или максимальное количество позиций в нём.

Бекап Opencart сайта - checklist

- Posted in Uncategorized by

Сайт обычно располагается в папке `public_html`.

  1. Папки `admin`, `catalog`, `download`, `system`, а также файлы `.htaccess`, `config.php`, `humans.txt`, `robots.txt`, `yandex_*.txt` -- это всё движок магазина. Те, кто использует VQmod, должны добавить к списку ещё папку `vqmod`.
    • файлы с точкой впереди - системные/скрытые. Поэтому их может быть не видно и надо включить в настройках FTP-клиента опцию их показа. `.htaccess` очень важен для работы сайта. Если у него есть расширение (.TXT или любое другое) - значит он сервером не используется (отключен). В этом случае не будут работать SEO URL;
    • в указанных папках есть 2 "лишние", их нежелательно включать в бекап: `system/cache`, `system/logs`. Это кешированные файлы и лог ошибок. Они нужны для работы и диагностики, но хранить их - смысла мало. Особенно если они большого объёма;
    • если вы пользуетесь VQmod-ом: папку `vqmod/logs` желательно исключить из бекапа. Папку 'vqmod/vqcache' можно бекапить, а можно и нет. Самое ценное здесь - содержимое `vqmod/xml`. Остальное несложно восстановить.
  2. Вторая важная часть сайта - картинки/фото.
  3. Они находятся в папке `image` (`public_html/image`). Оригиналы картинок - в папке `image/data`. Это самое ценное. Остальное несложно восстановить.

    • Что здесь бекапить: всю папку `image` за исключением `image/cache`
    • `image/cache` очень объемная. Эти файлы генерируются сайтом на лету при просмотре сайта. Ссылки на них могут использоваться в `sitemap.xml`.

  4. Третья критически важная часть сайта - база данных магазина. Её через FTP не скопируешь. Её надо бекапить либо Adminer-ом, либо phpMyAdmin (обычно есть в панели управления хостинга).

SafePatch - альтернатива vQmod

- Posted in Webdev by

Идея патчей и vQmod совершенно одинаковая. И в одном, и другом случае файл с изменениями накладывается на некую известную основу. И если эта основа изменилась -- и патч, и vQmod могут "поломаться": не смогут внести изменения, если не найдут точного соответствия, необходимого для внесения правок.

Поэтому те, кто наивно полагает, что vQmod спасёт их от всех бед и является волшебной таблеткой и позволит без проблем обновлять версии и ни о чем не беспокоиться - сильно заблуждаются.

А те, кто знает об этом и вынужден хоть так, хоть иначе контролировать логи ошибок -- знают, что заниматься отладкой vQmod гораздо менее удобно, чем иметь изменения сразу на месте, в коде, и не гадать, откуда именно берется исполняемый код и где его искать в исходниках.

К тому же vQmod - рантайм решение. То есть работает при каждом запросе к серверу. Конечно, многое решается кешированием. Но я из тех разработчиков, которые не совсем понимают, зачем нужно вводить лишнее звено, если то же самое делается без дополнительных костылей (а технологии внесения и убирания этих изменений существуют уже лет 40 и протестированы не одним поколением программистов -- я говорю об утилитах patch и diff).

Причём убрать изменения так же просто, как и наложить патч.

Применить изменения к коду: git apply fix-some-problem.diff или patch -p1 fix.diff

Убрать изменения: git apply -R fix-some-problem.diff или patch -R fix.diff

И где здесь сложная часть? Это ничуть не сложнее удаления VQmod файла. При использовании vQmod надо управляться с набором XML файлов. При использовании стандартного подхода -- с набором DIFF файлов. Невелика разница. А преимущества серьёзные.

И вот совсем недавно, в поисках PHP-реализации утилиты patch или автоматического конвертера DIFF в vQmod XML, я наткнулся на замечательный вариант: утилиту SafePatch.

http://code.google.com/p/safepatch/

UPD: в связи с закрытием Google Code проект переместился на Github: progerxp/safepatch.

Если кратко и своими словами -- это "менеджер пакетов" (расширений). Но в отличие от vQmod (runtime) он эти изменения вносит непосредственно в исходный код (как и patch). При этом понимает формат VQmod и может использовать эти файлы тоже.

Так что те, кто интересуется вопросом - встречайте. По-моему, хороший инструмент. Это не совсем то, что я искал, но отличное готовое решение проблемы.

See also:

На чём пользователи читают почту

- Posted in Uncategorized by

Всё больше почты читается на мобильных устройствах.

По статистике компании Ecwid, 65% их рассылок читается на айфонах, около 16% - на андроиде. Остальные платформы (десктоп и веб-клиенты) идут дальше с существенным отрывом.

Даже если цифры распределения неточные - тестируйте, как ваши рассылки и письма выглядят на мобильных устройствах.

То, как вы пишете письма, включая квотинг (в первую очередь его бесполезный объём) и стиль изложения -- тоже крайне важно. Тот, кто никогда не пытался пользоваться смартфоном для переписки, обычно допускают следующие ошибки:

  • включают весь текст письма в ответ. Это жутко неудобно на маленьком экране. Или вы думаете, что ваш собеседник успеет всё забыть, пока вы пишете ответ? Совет: включайте только небольшую часть в квотинг, 1-2 строчки. Если вы отвечаете на большое письмо со множеством затрагиваемых тем. Это позволит собеседнику восстановить контекст беседы. Остальное он и так помнит, если речь не идёт о службе поддержки с несколькими десятками обращений в день;
  • не отделяет абзацы пустой строкой. Отличить, где начался ответ, а где ещё конец отквоченной фразы, крайне сложно - на эти поиски уходит в несколько раз больше времени. На десктопе это часто разукрашивается, поэтому граница заметна, в мобильных почтовых клиентах обычно есть только текст. Помните об этом;
  • пытается обсудить 10 тем в одном письме. Письмо становится огромным (то, что на десктопе занимает всего один экран - на мобильном надо пролистать раз 20, а то и больше), на него становится крайне сложно ответить сразу с телефона (попробуйте с этой горой поработать, пытаясь отрезать часть или листая туда-сюда в попытках вспомнить всё, на что надо ответить). Совет: напишите лучше 10 мелких писем. Одно письмо - одна проблема (тема);
  • включают километры подписей и приветствий. Особенно длинными подписями страдают те, кто что-то продаёт - вы наверняка видели подписи по 5-6 строк. Может иногда они и нужны, но поверьте - обычно всех контактов достаточно в первом письме. Во всех следующих вполне достаточно 1-2 строк подписи. Всякие приветствия я вообще никогда не читаю и всегда пролистываю, не глядя - места они на экране мобильного занимают много, а смысловой нагрузки в них никакой. Когда в день приходит по 50-60 писем, все эти излишки только мешают. Это раньше, когда письма были бумажными и шли неделями, витиеватые вступления были логичны. Сейчас же, когда человек контактирует ежедневно с десятками людей, а почта ходит со скоростью света, идеальный вариант - когда письмо сразу начинается с сути. Открыл - и ничего не мешает.

via Петр Диденко: На чём читают почту от вас?

См. также

https://twitter.com/qetzalcoatl/status/317287448646410240

Email Client Popularity (September 2012)

Mobile email now in the lead Earlier this year, our friends at Return Path predicted that mobile was to surpass web and desktop client usage by July, 2012. We found that this event happened as early as February, when mobile overtook webmail client usage. In April, desktop clients lost their top spot - and mobile has shown no signs of slowing down since. In the following graph, you can see how mobile market share has increased since we last updated our report in May, 2011, while desktop and web client market share has continued its shallow decline.

Киевстар: объем мобильного интернет-трафика за 2012 г. увеличился на 54%

По данным компании «Киевстар», за последний год количество смартфонов в сети оператора выросло почти вдвое. Как результат, объем мобильного интернет-трафика за 2012 г. увеличился на 54%. Для повышения пропускной способности сети и стабильности работы сервисов компания в прошлом году инвестировала в общей сложности 1.8 млрд грн (8 грн = 1$ USD) в развитие инфраструктуры сети. За 2012 г. было построено дополнительно 800 км волоконно-оптических линий связи. Теперь сеть «Киевстар» имеет общую протяженность более 44 тыс. км, из которых около 21,5 тыс. км – магистральных ВОЛС.