Очень долго я был в sape только вебмастером — соответственно, плевался на их вебмастерские интерфейсы и думал: ну, мало ли, вебмастеры ведь денег напрямую не приносят, деньги в систему только оптимизаторы вводят, значит все удобства и красоты в первую очередь для них.

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

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

Другой пример уёбищного сайта — scriptlance.com. Владельцы последние пару лет начали улучшать интерфейсы (в основном автоматизация вещей, которые раньше приходилось делать вручную), но до сих пор сайтом страшно пользоваться - очень мало javascriptа (я не фанат, но иногда он нужен), избыточная навигация и пр. Но люди пользуются, несмотря на.

Главное для сайта, предоставляющего услуги, — работающий механизм предоставления услуг. Рюшечки и паровозики важны, но совершенно некритичны.

Если Вы пользуетесь услугами iName.com.ua и довольны их качеством, Вы можете посоветовать наш сервис своим друзьям и посетителям своего сайта. Для этого Вы можете разместить на страницах своего сайта нашу кнопку:

Все мои хохлодомены зарегистрированы с помощью iname. Качеством услуг, предоставляемых iname, я доволен. Почему я решил посоветовать именно этот сервис?

(Нет, этот пост не проплачен, и никакой партнёрской программы у iname нет — это, по-моему, упущение: каких-нибудь 5%, и я бы повесил в сайдбар и ссылку на них, и их кнопку.)

Этот пост я решил написать потому, что рынок регистраторов — это чистая конкуренция, когда предоставляемые услуги идентичны и конкурировать у продавцов получается лишь за счёт сервиса. И как раз сервис у iname отличный:

• принимают оплату вебманями, причём берут сразу WMZ (в отличие от Оптимы, которая принимает только WMU);
• без проблем саппортят по телефону (правда, не по бесплатному);
• сделали очень удобный менеджер зарегистрированных зон, который поддерживает даже wildcard DNS.

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

Почтовые извещения тоже работают плохо: об окончании регистрации последнего брошенного мною домена я получил всего лишь 5 (пять) одинаковых писем.

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

Предположим, у них засбоил сервис (отправка извещения была вызвана два раза) и вместо привычных двух мне отправили в два раза больше — это четыре письма.

Но 5 писем как можно рационально объяснить? Ладно бы в пятом было написано “Срок регистрации доменногo имени истек!!!!1111“, но нет — все пять идентичны друг другу.

В общем, сервис хороший, но есть куда расти.

И да: за партнёрские комиссионные я бы рекламировал iname гораздо активней.

В минувший уик-энд я был на конференции украинских шароварщиков (они сами себя так называют, есличо).

Мне больше по душе термин ISV — Independent Software Vendor. Видимо, потому что классическая shareware в вебе (которым я и занимаюсь) встречается сравнительно редко, всё больше commercial software со 100% демоверсией на сайте вендора.

Пара тезисов, прозвучавщих на конференции (и запомнившихся мне):

1. Тратить на разработку первой версии продукта больше трёх месяцев нерационально.

   После трёх месяца разработок надо иметь по крайней мере бета-версию (We call it beta, because it’s beta than nothing) продукта, которую можно начинать продавать. Если продукт продаётся, его можно развивать дальше — в качестве guidelines можно использовать отзывы первых клиентов. Если не продаётся — отложить и переключиться на новый продукт. Иногда отложенный продукт начинает продаваться через полгода-год-x лет после запуска, “выстреливает” даже без дополнительной раскрутки. Позже можно будет доработать отложенный продукт (если появятся свободные ресурсы) и попытаться перезапустить его.

2. Продаётся не то, что лучше, а то, что лучше продаётся.

   Этот каламбур должен стать лозунгом для тех (micro)-ISV, которые предпочитают программировать до усирачки вместо того, чтобы продавать.

Существует особая категория инвалидов умственного труда — те, кто в качестве фтп-клиента используют Far Manager. (Пример другой категории умственных инвалидов — верстающие html в блокноте.)

Так вот, о FTP-функционале в FARе: очень часто инвалидам бывает необходимо выковырять из фара пароль к фтп-аккаунту (например, чтобы зайти на фтп из-под другого фара). FAR пароли криптует, так что простое нажатие F3 на фтп-панели не помогает.

Для того, чтобы вытянуть фтп пароли из фара, можно воспользоваться специальным инструментом от Игоря Берковича: FARPWD.

Если этот инструмент у вас не запускается, ссылаясь на отсутствие COMDL32.OCX, то скачать этот ocх можно отсюда.

У меня тулза отказалась выковыривать пароли из аккаунтов, находящихся в папках — пришлось сначала скопировать аккаунты в фтп-корень, а затем воспользоваться FARPWD.

Изящная утилита, позволяющая заиметь до четырёх виртуальных десктопов на вашей Windows: Desktops v1.0.

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

Стабильно работает, несмотря на свой детский размер — zip с екзешником занимает всего 62 kb, программа не требует инсталляции. Последнее особенно удивительно, ведь программу написали в Microsoft.

У меня эти виртуальные десктопы работают под XP.

Одна беда: Desktops совсем не дружит с Free Launch Barом — приложения, запущенные с помощью FLB’шного hotkey всегда открываются в первом десктопе, без учёта того, в каком десктопе ты нажал hotkey.

Тем не менее, если вы не пользуетесь FreeLaunchBar, то попробуйте эти виртуальные виндоуз десктопы, хотя бы в качестве эксперимента. Например так: в первом десктопе рабочие приложения, во втором — нерабочий сёрфинг и мессенджеры. Сразу станет очевидно, чем вы занимаетесь в текущий момент времени: работаете (тогда включен первый декстоп) или нет.

Киев, 20 сентября.

Олсо, останусь на 21-ое.

Яндекс запустил собственный мессенджер.

Google выпустит бета-версию собственного браузера.

Ну, наконец-то.

У любой компании, занимающейся разработкой для веба, рано или поздно возникает желание написать нормальный браузер для своего приложения, а не бороться за кроссбраузерность с существующими.

Неудивительно, что у Гугла первого лопнуло терпение.

Следующий шаг — выпуск собственной операционки: когда гуглограммистам надоест бороться с граблями операционнок.

А если серьёзно, то для вебразработчиков этот Хром (Chrome) выльется в +1 браузер для тестирования кросс-браузерности.

Даже если Гугл переманит половину пользователей IE (у MS сейчас 80% рынка), поддерживать IE всё равно придётся. Файерфокс отвоевал меньше 20% рынка, даже с маркетинговой помощью Гугла.

Разработчик мега-плагина для вордпресса “SpamKarma” о вордпрессе:

I will really try to keep that one short, because I could probably write a novel of that. And it wouldn’t be a very interesting read.
In a word: Wordpress kinda sucks nowadays. Its retarded upgrade rate makes it nearly impossible to keep up, in turn making it a constant security threat on my servers. And each time I finally cave in and install one of those “mandatory security upgrade”, it also installs 600 Ko of other theme compatibility-breaking fluffy crap that I never asked for in the first place. Usually setting the ground for the next cycle of security-exploit-rushed-upgrade. To sum up, it’s become incredibly bloated and tedious to support. Replacing it on my own servers is very high on my list of things to do (which means somewhat in the first 1000 items).

В переводе на русский: вордпресс сосёт, причмокивая.

Причём сосёт причмокивая настолько громко, что единственным стимулом писать что-то под вордпресс для меня являются деньги. Потому что такое govno inside, что никакого терпения не хватает.

Вот вам и Open Source: ни одного нормального бесплатного блог-движка на php до сих пор нет. Палю нишу, типа.

В частности, Windows.

Любой софт, каким бы идеальным он не был, имеет баги. Кстати: хорош тот софт, чьи баги позволяют к ним приспособиться и пользоваться софтом, несмотря на. Но сейчас не об этом.

Самый простой способ разобраться с ошибкой — вбить её текст в google и почитать, что написали пользователи, сталкивавшиеся с этой ошибкой раньше.

Этот способ позволяет разобраться с приблизительно 90% всех ошибок (не только пользовательских, но и программистских — дебажить с гуглом гораздо веселее, чем без него, хоть это и расслабляет, отучая мозги думать).

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

А у локализованного софта пользователей гораздо меньше, чем у нелокализованной версии. Соответственно, поиск по локализованному тексту ошибки даёт меньше результатов, чем поиск по её оригинальному тексту. Проблема в том, что не всегда удаётся точно перевести сообщение об ошибке на язык оригинала (отдельный привет надо передать локализаторам).

А винда у меня (к сожалению) русская, т.к. покупалась вместе с ноутом.

Столкнулся с необходимостью выбрать инструментарий для ведения документации по проекту. Получается, что если в команде нет отдельного (специально выделенного) человека, который ведёт всю документацию, то инструментарий должен поддерживать коллективную разработку документации. Как минимум — уметь делать versioning, diff и rollback.

Два ключевых слова — “документация” и “коллективная” приводят к очевидному решению — wiki. Решение настолько очевидно, что можно найти testimonials людей, использовавших wiki для документирования разработки software:

Во-первых, в разработке док участвовали все: манагеры, девы, кюэйцы. Каждый со своей позиции (решая профильные вопросы) и в целом.
Во-вторых, оценивать изменения состояния проекта было легко. У нас была круглосуточная разработка (головной офис в штатах) и поэтому за время сна могло многое измениться.
В-третьих, самые болезненные места было сразу видно и можно было прямо с утра озадачиться раздачей пинков в нужных направлениях. Или тут же решить самые острые вопросы (поменяв заодно тег вопроса на тег ответа). Или поставить новые проблемы в ответ на.
В-четвертых, документация была всегда у всех под рукой. Гибкая. Актуальная.
В-пятых, она активно росла. Было негласное правило: хочешь задать вопрос по теме, которая еще не описана? Впиши все, что ты помнишь, в той мере, какой считаешь нужным.
В-шестых структуру самого дерева мы регулярно реструктурировали, что позволяло нам при проектировании новых кусков логики опираться на схему уже существующих.

Очевидно, что сама по себе wiki не справляется с задачей: нужны костыли для привязки к багтрекеру, svn-у, php-docу (или его аналогу). Ещё более очевидно, нужен “архивариус” — человек, который будет поддерживать порядок в документации, реструктуризировать дерево. Похоже, что при определённой активности и дисциплинированности пользователей (т.е. разработчиков, тестеров и менеджеров) роль архивариуса удастся свести именно к поддержанию порядка.

При этом меня не покидает ощущение того, что wiki-разметка — это недо-html. А в компании, занимающейся web-разработками, основы html знает даже корпоративная морская свинка™. Спрашивается: зачем людям, знающим html, насиловать себя и писать вместо <i>привычных тегов</i> //какие-то недотеги//, которыми они нигде, кроме этой самой wiki не пользуются, в отличие от нативных html тегов?

Среди всех претензий к wiki её недо-htmlьность — самая мелкая.

А теперь самое время вернуться к тому, с чего всё это начиналось: нам нужен инструмент, позволяющий вести коллективную разработку документации. Как минимум — уметь делать versioning, diff и rollback.

А ведь у нас уже есть такой инструмент: это Control Version System, система контроля версий. Стандартная CVS позволяет делать versioning, diff и rollback для текстовых файлов.

Итак, самое дешёвое решение — вести документацию в текстовых файлах, контроль версий возложит на CVS, которая уже есть в проекте. Грубо говоря, если в CVS есть директория Source с исходниками проекта, то рядом надо сделать папку Docs с его документацией в текстовых файлах.

Беда в том, что документация — это не текст. Даже если обойтись без таблиц, иллюстраций и форматирования, документация — это как минимум гипертекст. Значит, надо вести документацию в формате html, и хранить её в CVS, ибо html файл — это текстовый файл. Редактировать документацию сможет каждый, как и в случае с wiki — для этого подойдёт любой html-редактор, даже блокнот.

Versioning для html файлов будет по-прежнему обеспечивать CVS. Единственное, что надо согласовать — это правила форматирования документации в html. Типа: для жирного используем <b>, а не <strong>; абзацы делаем с помощью <p>; ссылки ставим только относительные. Точно такие же соглашения существуют и в отношении кода: как ставим {скобки}, что используем для табуляции — пробелы или табы.

Соорудить надстройку над этой документацией в формате html не очень сложно: нужны индексы (предметные указатели), нужен поиск, нужны пути, нужен список последних правок, нужны специальные теги для багов и вопросов. В общем, костыли кажутся не более сложными, чем костыли для wiki.

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