Блог Александра Башкирова

ИТ и бизнес, компьютеры и ПО, фото, программирование и просто мысли…
Этот сайт в основном посвящен тому, что мне интересно вне работы. Ведется в порядке хобби.
Все изложенное на сайте - мое частное оценочное мнение и не может быть истолковано иначе.
Со всеми вытекающими из этого последствиями.

Плагин для WordPress – Russify Comments Number

Совершенно случайно нашел классный плагин для Wordprss - Russify Comments Number (автор - Александр Улизько - http://ulizko.com/). Плагин приводит в человекочитаемый форме количество комментариев к записи. Например, "Один комментарий", "Два комментария", "Пять комментариев" и т.д.

Плагин легко устанавливается, и не требует настройки, работает как часы. В общем - однозначно рекомендую!

Принятие решений при выборе ПО.

В тему недавним рассуждениям коллег (Тенцера и Марианны).

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

На самом деле, решения могут быть приняты двумя путями:

  • самостоятельно
  • при помощи внешних консультантов

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

Попытаемся рассмотреть его более пристально. На решение о выборе того или иного ПО могут повлиять причины следующего характера:

  • объективная оценка (относительно объективная, на основании взвешенного анализа... - см.выше)
  • политические причины (могут быть самые разные. Основная - "стоит у дружественной/братской компании, стоит в холдинге". Как вариант - "акционеры/директора/управляющие разработчиков связаны с нашими акционерами/директорами/управляющими".)
  • личностная (субъективная) оценка. (оценивает тот или иной менеджер с тем или иным уровнем профессионализма, соответственно, решения варьируются от "мне нравиццо, надо брать" до "стоит брать, потому что архитектура (обоснование) и функциональность (обоснование) нас вполне устраивают")

Вопрос - учитываются ли рекомендации рядовых специалистов при выборе того или иного ПО? Варианты ответа:

  • иногда да (действительно, иногда прислушиваются к специалистам. Весь вопрос в том, что они должны быть действительно СПЕЦИАЛИСТАМИ, а не подмастерьями)
  • а оно надо? (как вариант. Часто жизнь складывается так, что мнения рядовых специалистов топов не интересует - сказано поставить и внедрить, извольте исполнять!)
  • специалисты должны дать базис для принятия решения (это лично мне ближе; так как учитывается и опыт "снизу", и требования "сверху")

Что еще? Если делать по-умному, то перед тем как выбирать, надо попробовать. В идеале - сделать тестовый запуск на ограниченном числе автоматизируемых процессов (один-два). И поковырять систему недельку-другую. Хорошо? - Да. Но накладно, и требует установки системы, не говоря уже о том, что банально нужны договоренности с разработчиками/поставщиками ПО и люди - тестеры. Тем не менее - весьма любимый мной вариант. Вероятность "обжечься" резко падает по сравнению с "котом в мешке".

Еще один интересный момент. Предположим, есть 10 (а лучше, как в анекдоте - 20) систем, автоматизирующих область Х. Нужно выбрать одну. Что делаем? Классика жанра состоит в том, что строим классическое (простите за тавтологию) сито:

  1. Формируем требования (а куда же без них, в конце концов надо представлять, что хочет бизнес-заказчик)
  2. Формируем критерии отбора
  3. Отбираем пару-тройку лидеров (самый интересный момент, о нем как раз я подробно написал выше)
  4. Разворачиваем их
  5. Тестируем (имитируем работу пользователей, возможно - с некоторыми допущениями)
  6. Делаем орг.выводы
  7. Принимаем решение (тоже см.выше).
  8. Подписываем договор, и на внедрение (совсем отдельная песня).

Как оно бывает на самом деле - не мне вам рассказывать:) Вопрос - часто ли срабатывает подобная классика? К сожалению, практически никогда. Почему? Да потому, что:

  • цели внедрения запросто могут быть не определены;
  • требования к продукту существуют в 3..4 головах, причем - разные;
  • критерии отбора сформировать невозможно, т.к. непонятно, что выбираем;
  • понимания, какие системы можно рекомендовать - нет, так как все равно выберут за нас;

Тогда последний вопрос: как жить дальше? Да так: исправлять ситуацию, где возможно, где можно - помогать выбору, где нельзя - подстраиваться и выжимать максимум бизнес-перспектив из поставляемого ПО. В общем, жить полной жизнью и не скучать:)

Кросспост из моего ИТшного блога на ITBlogs.ru

Google Calendar & Sunbird

Данная статья безнадежно устарела. Оставляена для истории.

Для планирования повседневной работы я использую Sunbird от Mozilla. Замечательный календарь-планировщик с парой недостатков:

  • не умеет синхронизироваться с Pocket PC Outlook 2005
  • не умеет синхронизировать записи "домашнего" и "рабочего" Sunbird'a.

Вот о решении последней проблемы и пойдет речь (коллеги присоветовали). Идея проста - использовать для синхронизации посредник, в роли кторого будет выступать сервис Calendar от Google. Дело в том, что Sunbird позволяет одновременно отображать больше, чем один календарь, и его можно научить работать с внешними календарями. Итого, нам потребуется:

Забегая вперед, скажу, что остановился я на первом варианте с плагином - так как второй вариант у меня просто не заработал. Итак, по шагам, в случае плагина:

  • Заводим аккаунт на Google (я этот шаг пропустил, так как аккаунт у меня уже есть)
  • Создаем на календарном сервисе Google календарь
  • Скачиваем sunbird (у меня уже был скачан)
  • Скачиваем плагин
  • Устанавливаем плагин в sunbird
  • Получаем на Google ссылку на календарь (Google в этом смысле просто шикрен: можно получать xml, rss или iCal - я выбрал его)
  • Подключаем созданный календарь в sunbird ("Файл" - "Подписаться на удаленный календарь" - "Из сети" - ...)
  • В процессе подключения выбираем другой цвет для G-календаря (для наглядности)

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

Теперь об общих впечатлениях: работать с Гугловым календарем через sunbird довольно приятно, правда, есть и ложка жегтя - судя по всему, автоматическое обновление не работает. То есть в sunbird надо периодически нажимать Ctrl-R, а в G-календаре - либо Ctrl-F5, либо жать на логотип.

Главная же "фишка" состоит в том, что можно запросто синхронизировать свой рабочий и домашний (а в перспективе - какой угодно) sunbird, не особо заботясь о формате данных и платформе, на которой он работает. Также можно использовать предложенное решение как средство calendar-collaboration - то есть для ведения совместных с коллегами календарей. При этом, как я уже говорил, календарей в один sunbird можно подключить столько,сколько надо - и таким образом легко разводятся "общественные" и "личные" вещи;)

Осталось теперь научиться синхронизироваться с WM2005.

Погоди выполнять, отменят!

Не думай о секундах свысока... натолкнулся на замечательный пост о том, как надо и как не надо давать поручения. На ITBlogs он прекрасно пошел как дополнение к моему посту "В пользу бедных", а здесь, ввиду того, что комментарии для ITBlogs постов закрыты, решил привести прямую ссылку: Принцип ПВО. Ситуация, описанная в посте, довольно жизненная, но могут быть вариации, в частности, "важные поручения" могут быть выданы не только письменно (по email, в бумажном виде), но и устно, при личной встрече, или вообще - через "третьи руки" (самый интересный случай, когда кто-то просит кого-то озадачить кого-то еще, на эту тему я вроде как уже писал)...

Грустно как-то. Неужели так - ВЕЗДЕ?

Lazarus – свободная среда программирования для Linux и Windows

Данная статья устарела. Оставлена для истории.

Когда-то давным-давно (лет, наверное, 8..10 назад) я программировал на Delphi. Программировать мне откровенно нравилось, правда, через некоторое время от GUI программирования я отошел, сконцентрировавшись в основном на WEB программировании. Немалую роль в этом повороте сыграло то, что Delphi мягко говоря, не совсем бесплатная среда, а очень даже платная. (И ряд других обстоятельств;)). Но это - предистория...

Некоторое время назад, совершенно случайно, наткнулся на свободную (open source) реализацию языка Pascal. Называется это чудо FreePascal, и живет по адресу http://www.freepascal.org/ Возможности довольно широки: декларируется возможность разработки под все возможныеWindows, Linux, FreeBSD, MacOS и т.д.

Цитирую с сайта FreePascal:

Free Pascal (aka FPK Pascal) is a 32 and 64 bit professional Pascal compiler. It is available for different processors: Intel x86, Amd64/x86_64, PowerPC, PowerPC64, Sparc, ARM. The discontinued 1.0 version also supports the Motorola 680x0. The following operating systems are supported: Linux, FreeBSD, Mac OS X/Darwin, Mac OS classic, DOS, Win32, Win64, WinCE, OS/2, Netware (libc and classic) and MorphOS.

У проекта есть русскоязычный сайт: http://www.freepascal.ru/

Дальше, в процессе изучения этих сайтов, было выяснено, что в мире существует свободная (open source) среда разработки под FreePascal, которая называется Lazarus. Lazarus живет по адресу http://www.lazarus.freepascal.org/ Установка Lazarus на Windows показала, что эта среда полностью аналогична "той самой Delphi". Именно аналогична, т.к. в тестовом приложении было обнаружено несколько незначительных отклонений от того, что я помнил с delphi-УстановкА вот про установку Lazarus на Linux можно написать отдельный трактат... То есть, вроде как все "встает", но не с первого раза - библиотеки требуются точно той версии, с которой работает Lazarus. В итоге, гугление привело меня к отличной статье "Установка Lazarus на Linux", с помощью которой, а также с помощью http://www.rpmfind.net , Lazarus был установлен и опробован (кстати, несколько требуемых библиотек я взял от Мандривы).

Первые впечатления:

  1. Судя по всему, при помощи Lazarus можно создавать кроссплатформенные приложения
  2. Абсолютно точно можно создавать порты одного и того же приложения под Windows и Linux
  3. Код, генерируемый Lazarus (Linux версия), довольно объемен: простая форма с 2 элементами и одним обработчиком события "вести" 16Мб. На мой взгляд - многовато! Возможно, можно оптимизировать.
  4. Через yum Lazarus на ASP Linux (12) не ставится:)

Будут еще впечатления - обязательно поделюсь.

Liferea: rss reader для Linux

Просмотров: 2020Комментарии: 2
Linux

Открыл для себя Liferea - читалку rss под Linux. Купила она меня тем, что ее интерфейс очень похож на интерфейс Mozilla Trunderbird. Живет эта софтина по адресу http://liferea.sourceforge.net/. Насколько я понял, она "по умолчанию" включается в большинство дистрибутивов, по крайней мере, в мой ASP Linux 12 она была включена.

Скриншот Liferea

 Собственно говоря, Liferea купила меня тем, что в ней есть все, что необходимо, нет ничего лишнего, все удобно и нет проблем с кодировками. Может быть, невнимательно смотрел - но под Windows таких клиентов я не встречал. Хотя, предполагаю, что что-тто подобное почти наверняка имеется.

В общем, смело рекомендую как легкое и изящное решение для чтения RSS.

В пользу бедных

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

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

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

В общем, жизнь - это вечный поиск компромисса. Во всем.

Кросспост из моего ИТшного блога на ITBlogs.ru