Ruslan Brest, rb.labtodo.com
Backend web-developer: CodeIgniter, PHP, MySQL, OpenCart, PrestaShop, MaxSite CMS

pros-cons

Что даёт установка минимальной цены расширений продавцам и покупателям

На опенкартфоруме возникла тема-предложение по оптимизации процесса продаж в каталоге шаблонов, инициированная продавцами шаблонов. Цель благая, но основой предложения является:

  • установка нижней планки (минимальной цены шаблонов);
  • и кол-во продаж за определенный период.

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

Топикстартер выразил уверенность, что эти меры заставят "некачественных" продавцов подтягивать уровень шаблонов.

Меня это рассмешило. И вот почему.

Далее...

Selfoss RSS reader: первые впечатления

Итак, впечатления первых суток использования Selfoss как возможной замены TT-RSS (Tiny Tiny RSS).

Pros:

Далее...

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

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 нет. И как они предлагают следить за интересующими обновлениями? На сайт заходить? Как фейсбук? Странные люди. Ни туда, ни туда я в итоге вообще не захожу.

Далее...

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

Идея патчей и 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:

Почему я уважаю email (и может ещё Jabber), а скайп, аську и прочую чатико-переписку (VK, FB) -- нет

Преимущества email:

  • не отвлекает тогда, когда ему хочется. В работе программиста это очень важный момент. Критически важный;
  • Переписка может без доп. усилий храниться в одном месте, на сервере. И быть доступной с нескольких компьютеров (в т.ч. чужих) и телефонов;
  • возможность сводить переписку в единое место -- это возможность настроить раз единые правила фильтрации и постепенно их дополнять;
  • простота - друг совершенства. Настроить уведомления на SMS при поступлении почты от определенной группы собеседников или при срабатывании какого-либо правила -- никаких проблем. Отфильтровать и настроить такое уведомление в ICQ/Skype... Ну-у-у, попробуйте. И учтите весь зоопарк устройств, которые могут понадобиться;
  • правила обработки email могут храниться и обрабатываться на сервере. Необязательно держать у себя включенное и подключенное к интернет устройство, чтобы оно занималось фильтрацией (а 99.99% времени - простаивало и жрало батарейку без всякой пользы). И не надо головной боли при смене устройства. Получил SMS о чем-то важном в почте - подключился, забрал почту, читаешь.

Аська, скайп, телефон:

  • очень мешают тем, что могут прервать мыслительный процесс в самый неподходящий момент;
  • историю хранить в едином месте нереально. Особенно этим страдает Скайп и телефон;
  • в телефоне логов разговоров вообще не остается. Особенно при деловых разговорах. Или обсуждении деталей задач. Или условий. Человек иногда с удивлением узнает, что именно он говорил или писал, когда видит логи. Даже самый искренний. Потому что совершенно искренне считал, что сказал по-другому. И привычка фиксации часто спасает от скандалов. Речь вообще даже не о злом умысле. Просто об особенностях психологии и памяти человека в стрессовых условиях;
  • Скайп имеет самый идиотскую реализацию просмотра истории и поиска, которую я видел. А внутренности логов лежат не в виде текста, HTML или XML, а в бинарном виде. Но если бы это позволяло ему хотя бы быстро работать... Так нет же. Дождаться загрузки длинного лога - целая вечность проходит;
  • если угораздило обсуждать что-то важное в дороге и забыл или не смог перенести это вовремя на десктоп или в онлайн-хранилище -- найти потом, где это было, когда и на каком девайсе -- целый подвиг. Особенно если дел много. Перенести с телефона важные детали или присланные в процессе разговора длинные ссылки -- сплошная головная боль, потому что мобильные ICQ/Jabber клиенты обычно понятия не имеют об экспорте. Совсем другое дело при использовании email.
  • в аське часты сообщения "привет" и "ты здесь?", после которых нет ничего. Представьте себе, что чувствует занятый человек, просматривая раз в 10-30 минут накопившиеся сообщения, чтобы ответить на самое важное, а остальные минут 20-30 иметь возможность посвятить очередной задаче без отвлечений? Я на такие вопросы и приветы обычно вообще не отвечаю, и вот почему. Если есть что-то важное - человек обычно пишет о проблеме сразу, а я могу быстро отреагировать, когда в свободный промежуток увидел конкретный вопрос среди десятка других бестолковых сообщений-пустышек. Если там только "приветы", то обычно человеку просто одиноко и разговоры в аське превращаются не в решение проблем, а долгое обмусоливание и размышления вслух;
  • обсуждение одного и того же вопроса по email занимает 10-20 минут, в ICQ/скайпе -- минимум час-полтора. Поскольку в разговоре возникают паузы (то у одного, то у другого собеседника) и писать "словесного мусора" приходится гораздо больше, чем обычно пишешь в ответе на email. В общем, чат отвлекает от дел гораздо больше;
  • использование IM и чатов приводит к более частой отсылке отрывочных фраз, не всегда полностью завершённых, которые нетерпеливый собеседник может прервать новыми вопросами и обсуждениями, не дождавшись конца мысли. В итоге идёт винегрет обсуждения, часто нескольких вопросов, и разобраться в этой каше, что к чему относится, впоследствии становится очень трудно. Кто читал логи бурных быстрых обсуждений в попытке выловить из них конкретные задачи, планы и историю обсуждения вопроса или нескольких - поймёт, о чём речь. Кто пытался восстановить ситуацию по вчерашним-позавчерашним срочным разговорам, когда приходится переключаться между несколькими проектами (и все подробности в голове просто не удержишь) -- тоже в курсе проблемы;
  • иллюзия постоянной доступности человека в аське/скайпе/джаббере - лишь иллюзия. Когда именно я увижу сообщение - зависит лишь от наличия свободного времени, а не от сигнала. Чаще я смотреть туда не стану по каждому прерыванию, поскольку не в службе поддержки работаю, а для работы мне надо сосредоточиться и иметь возможность думать о задаче в течение достаточно длинных промежутков времени. Программисты так устроены: мы держим в голове массу деталей и связей, и нам надо построить в голове модель происходящих процессов, чтобы в ней ориентироваться. И если задачи сложные, а не 5-минутные, любое отвлечение способно разрушить весь этот воздушный замок и процесс "втягивания" приходится начинать заново.

Резюме

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

В общем, поймите: не человек - придаток машины, реагирующий на звоночки, а машина является инструментом думающего человека. И только человек решает, отвечать ли на звонки (как телефонные, так и их аналоги), когда он занят. А когда свободен - почту проверять раз в пять минут и чаще никто не мешает, уведомления на SMS получать тоже. Поверьте, скорость получения уведомлений там ничуть не хуже, чем у IM-клиентов.

Поэтому я за почту.

Скорость реакции на почту и IM - одинаковая (сюрприз!). Поскольку всё равно определяется скоростью моей реакции на ситуацию, а не скоростью света и чьими-то желаниями.

Hint: как облегчить другим работу с вашими письмами

Несколько мелочей и микро-правил, которые способны сделать другим жизнь проще при работе с вашими письмами.

Необязательно, но весьма желательно:

  • Никакого HTML оформления. Забудьте. Только plain text;
  • приветствия в эл. письмах при регулярной переписке -- штука бесполезная. То же самое обычно можно сказать о цитировании и перечислении даты и времени письма, на которое отвечаем. Через некоторое время люди перестают обращать внимание на эти служебные строки, иногда там просто "слепое пятно" образуется. Если на большом экране эти 1-2 строки мы просто "пропускаем мимо глаз", то на смартфонах это занимает пол-экрана. Лучше, когда сразу идёт текст по делу;
  • то же, но в меньшей степени, относится к подписи. Уместно в первом письме к новому собеседнику включить полную подпись со всеми контактами и телефонами, а в последующих, если переписка уже длится некоторое время, лучше иметь короткий вариант: с 1-2 контактами или единственной ссылкой на сайт (на страницу со всеми контактами). То ли на персональном сайте, то ли где-то в соцсетях (Linkedin, VK, Facebook, Google+), то ли в блоге (Livejournal, Wordpress, Blogspot и т.п.) Иметь сейчас страницу с полным списком контактов совсем несложно, заводить для этого свой сайт-визитку необязательно.

Внутренности писем:

  • разделяйте абзацы пустой строкой (два раза Enter, а не один). Если отвечаете после цитаты - также отделяйте ответ пустой строкой. Не пишите сразу на следующей строке после квотинга. Этим вы спасёте мозг и пальцы тех, кто работает с почтой на мобильных устройствах (смартфонах, в частности);
  • атомарность, одно письмо -- один вопрос. Лучше послать 10 коротких писем, чем одно большое с 10 разными вопросами. Это поможет легче работать с письмами как с задачами, а также спасёт в очередной раз мобильных пользователей (если не понимаете, о чём я - вы ни разу не пытались ответить на длинное письмо, находясь в пути и имея немного свободного времени). Как следствие - это способно значительно ускорить получение ответов: проще сразу ответить на 3-4 более простых вопроса с телефона, а пару более объёмных оставить для десктопа, чем если надо ответить на большое письмо с несколькими темами/проблемами. Редактировать большое письмо пальцами на смартфоне, пытаясь разбить его на более мелкие -- замучаешься;
  • если есть возможность - настройте почтовый клиент так, чтобы текст цитируемого письма располагался после подписи. Но в случае больших писем это будет неудобно. В случае с атомарными короткими сообщениями - очень удобно.

Hint: как облегчить себе работу с почтой

  • Исповедуйте правило пустого инбокса;
  • не пользуйтесь почтовым ящиком как хранилищем. Всё, что касается конкретных проектов - сразу сохраняйте в папке с проектом (если письмо вообще стоит хранить) в виде обычного текста. Имя файла должно включать как минимум дату (в ISO формате: YYYY-MM-DD). Можно ещё время, email или ник отправителя. Совсем необязательно сохранять одно письмо в одном файле: цепочки обсуждений удобно записывать в один большой файл (txt или markdown), а аттачменты складывать рядом (предваряя имя файла датой-временем). Но разрастание файла быстро становится неудобным, так что пробуйте и выбирайте по обстоятельствам золотую середину;

Не складируйте письма: всё, на что можно сразу ответить - отвечайте и удаляйте письмо. Не надо их разбрасывать по папкам, хранить в почтовом клиенте, сортировать с тем, чтобы когда-то почистить, создавать многочисленные правила автоматической сортировки. Всё это - пустая трата времени.

Что даёт сохранение писем в архиве в виде обычных текстовых файлов?

  • По ним легко и просто искать: как по именам файлов, так и по содержимому;
  • Их можно поместить в систему контроля версий для более удобной и надёжной работы с изменениями;
  • Их легко архивировать и переносить с проектом, не дёргаясь и не собирая хвосты из рабочего и личного почтового ящика, аськи, скайпа, IRC, и ещё Вася что-то с клиентом обсуждал отдельно в четверг, и ещё-не-помню-где=кажется-что-то-было... Всё, относящееся к проекту, собрано в одной папке, а не разбросано в нескольких программах. Возможно, у вас есть багтрекер -- это замечательно. Но тоже накладывает определенные ограничения. Если вы постоянно работаете в команде, и всегда в одной - пользуйтесь багтрекером. Потому что в этом случае велик шанс, что у вас есть дизайнеры и директор, далёкие от VCS, плюс ACL и клиенты с возможностью пускать их в PM/CRM/helpdesk инструмент с веб-доступом. Главное, чтобы было одно централизованное место для поиска всей связанной с проектом информации;
  • Из текстового `markdown` формата легко получить всевозможные красиво оформленные форматы: html, PDF, doc/ods/docx;
  • Рекомендую завести одно персональное место в качестве хранилища знаний (внешнего мозга), плюс в каждом проекте складывать в папку doc всю переписку и дела по этому проекту. Это позволит легко дать доступ к материалам проекта другим участникам при росте команды, а вас быстро приучит разделять личное (в т.ч. и личные проекты) и рабочее. Таким образом, у вас будет всего 2 места для поисков: либо в папке проекта, либо в персональном "внешнем мозге". У меня ещё есть отдельное "более медленное" место для материалов из интернета и книг. Там я храню их в запакованном виде и ищу по именам файлов и папок (файловой системе). Поскольку эти материалы более фундаментальные и реже используются для регулярной оперативной работы и редактирования.

См. также