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

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

Коммерческие Linux-фирмы.

Просмотров: 3245Комментарии: 4
Linux

Это наверное будет пост-поток сознания.

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

Для начала сделаем лирическое отступление. Что такое "коммерческая Linux-фирма"? Под этим названием, с моей точки зрения, скрывается два разных направления: первое, это те, кто выпускают дистрибутивы. И второе - те, кто оказывают услуги по установке/настройке/адаптации.

С первыми все понятно. Ну или почти все. Дистибутивы выпускают "большие" фирмы, для которых это либо способ возможной монетизации (Ubuntu - спорное, конечно, утверждение... но близкое к истине), либо тестовый полигон (RedHut, например). Ну, либо делать коммерческие и некоммерческие дистрибутивы одновременно (Alt Linux). Правда, как показала наша действительность, попытка сделать полностью коммерческий Linux в России обречена на провал (Linux XP благополучно почил в бозе - во многом благодаря ставке на только коммерческую лицензию).

А вот со вторыми... теми, кто оказывает услуги, все не так просто. Во-первых, "чистых" фирм, которые бы занимались "только Linux", нет. Ну или они мне неизвестны. Есть подразделения разных фирм, оказывающих разные услуги - но в чистом виде "только Linux" нет ни одной. Кто-то оказывает услуги по разработке ПО на заказ, кто-то - тиражирует книги, в общем - у всех есть второй "ручеек" денег. Это в общем неудивительно с одной стороны, а с другой - говорит о том, что народная мудрость о том что не стоит класть все яйца в одну корзину имеет под собой хорошее основание.

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

Но, что примечательно, по Linux "мастеров" нет. Я ради прикола позвонил в пару фирм, которые занимаются подобными услугами, там при слове Linux операторы впадали в ступор и говорили, что это не к ним.

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

В среднесрочной перспективе мне кажется возможны два сценария: либо "умрет Ubuntu" (давайте вспомним, то на данный момент это инветиционный проект), либо нет. Если нет - то Linux будет приближаться к простым пользователям - Убунта действительно "простой и человеческий Линукс", и, вероятнее всего, начнут появляться "чисто Linux-фирмы" (и не последнюю роль тут сыграют борцы за копирайт в мире ПО - они могут как усилить, так и ослабить данную тенденцию). А если убунта умрет... то тут все сложнее - те, кто сидит на ней, либо мигрируют, либо создадут свободное сообщество. Но и перспективы коммерцелизации Linux в этом слкчае будут туманны.

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

Да, и очень хочется надеяться на то, что мрачные прогнозы не сбудутся.

Резкий и конкретный

Просмотров: 2932Комментарии: 0
Alib.spb.ru

Пока ходил на собеседования, с удивлением открыл для себя странный факт: люди склонны путать понятия. Искренне заблуждаясь (надеюсь). Наиболее "хитовый" пример: перепутать резкость и конкретность в конкретном кандидате.

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

Работа: удовлетворение от сделанного

Просмотров: 2697Комментарии: 0
Работа

Есть на свете такая штука - удовлетворение от хорошо сделанной работы. И я ее периодически постигаю. Когда заканчиваю проект. Когда нахожу еще одно решение какой-нибудь ИТ-задачки. Когда изобретаю и привожу в действие очередной велосипед. Когда заканчиваю очередной проект. И особенно - когда вижу, как то, что делалось - работает.

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

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

Для памяти: сброс планшета 3Q RC0722

Просмотров: 6819Комментарии: 0
android

В общем, на днях мне удалось намертво повесить свой планшет - 3Q RC722. Не грузился, симптомы - выводил Login Screen на секунду и уходил в ребут.

Что сделал: методом научного тыка было выяснено, что можно войти в инженерное меню, если сразу же после включения (выключенного по питанию) планшета зажать кнопки "Menu", "Громкость +" ("+" на качельке громкости) и "Назад". После чего - нажать на включение. Планшет выведет на экран открытого робота (без меню). Для того, чтобы войти в меню - надо нажать на качельку громкости.
Выбор пункта меню - кнопкой включения. Для сброса к заводским настройкам - надо выбрать "Wipe Restore" и нажать кнопку включения (она играет роль кнопки выбора).
Да, в инструкции сказано о том, что надо нажать каким-то тонким предметом в какое-то специальное углубление... но я не обнаружил не специального углубления, ни какой-либо похожей на Reset кнопки. Зато я точно знал - Android, это такая штука, где есть специальное инженерное меню. 

Для памяти: диск 1C && Wine

Просмотров: 2683Комментарии: 0
Linux

В общем, запускал диски для детей производства 1С ("Я пишу грамотно!" и "Устный счёт"). В процессе запуска диск с консоли выдавал: 

err:module:import_dll Library MFC42.DLL (which is needed by L"E:\\data\\shell.exe") not found
err:module:LdrInitializeThunk Main exe initialization for L"E:\\data\\shell.exe" failed, status c0000135
Проблема очень понятная: Wine не хватает MFC42.DLL. Лечится, как выяснилось, элементарно:
winetricks mfc42
Рецепт отсюда.

Пост про то, как надо писать ТЗ

Периодически мне приходится в том или ином виде консультировать разные компании по поводу такого замечательного документа, как техническое задание на информационную систему.

И часто встречается ситуация, когда в роли ТЗ выступает все, что угодно... кроме, собственно, ТЗ. Почему так? Да потому, что ТЗ - это задание, на основании которого должна быть подготовлена система автоматизации. Не более - но и не менее. В роли ТЗ в общем случае не могут выступать прототипы экранов, список пожеланий и т.д. - потому что в итоге получится нечто, соответствующее ТЗ - но полностью или частично не соответствующее ожиданиям заказчика. Как избежать такой радостной ситуации?

Во-первых, всегда помнить - система, разрабатываетмая по ТЗ, автоматизирует процесс (напомню, речь идет о ТЗ на информационную систему - от интернет-магазина до ERP). Соответственно, в ТЗ обязан быть прописан процесс, который автоматизируется. Иного просто не дано: не понимая процесса, невозможно описать систему.

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

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

Дальше имеет смысл расписать требования к формам и дизайну. Требования к формам, в идеале - это выделение критически важной информации длдя процесса, с анализом - когда, кто и в каком объеме поставляет нужную информацию. Требования к дизайну тут получаются вроде бы как не очень логичны... но логичны, потому что важно не только то, что будет нести форма в себе - но и то, как она будет выглядеть. Хотя требования к дизайну можно вообще поставить в конец ТЗ, или сделать ссылку на brandbook - тут вариантов масса.

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

Дальше, собсвтенно, если есть понимание на какой базе строим ИС - нужно расписать это. Если ИС создается "с нуля" (бывает и такое) - то указать, на каком яыке она пишется, какие библиотеки требует и т.д.

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

Дальше, нужно описать, что надо будет сделать, чтобы ввести систему в эксплуатацию.

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

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

Финальным аккордом нужно описать процедуру приемки-передачи системы (в целом и по каждоому этапу). А также привести требования к информационной безопасности.

Получилось довольно много? Да, а кто говорил, что будет просто? На данный момент я написал, наверное, более сотни разных ТЗ - и по итогам работы над этими докумнетами пришел к выводу о том, что если писать документ не ради документа, а ради работы - то он по любому получится большим. Не потому что я так хочу, а потому, что по-другому просто не получится. Тут или качество, или расходящийся процесс.

В общем, получился почти на тему "как написать ТЗ" :) И, прошу отметить - никакого ГОСТа. Хотя структура получилась в чем-то похожей на то, что трбует ГОСТ 34 от ТЗ. Но, наверное, его проектировали, исходя из аналогичных (или в чем-то похожих) соображений.

С Новым 2014 годом!

Просмотров: 2462Комментарии: 0
Alib.spb.ru

Друзья, коллеги, читатели, все-все-все!

Искренне поздравляю Вас с Новым 2014 годом!

Здоровья вам, маленьких и больших личных свершений, радости и решения всех проблем. А также отсутствия новых :) А также - чтобы все на всех планах было хорошо. Радостно. Правильно. Пусть сбудется все хорошее!!!

С Новым Годом!