Некоторые соображения о Windows 10

Подробности можно прочитать тут: CNews, PCWeek. Хочу обсудить самые интересные новые функции:

Меню "Пуск"

Рабочий стол и меню пуск пользователь обычно открывает только для того, чтобы запустить нужную ему программу. Т.е. на рабочем столе и в "Пуске" пользователь проводит минимальное количество времени. А значит мельтешить плитками совершенно бесполезно: никто не будет сидеть и любоваться как они красиво переворачиваются.

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

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

С другой стороны очень заманчива идея объединения рабочего стола и меню "Пуск". Ведь по факту- это дублирующиеся сущности и от этого избавиться было бы правильно.

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

Виртуальные рабочие столы

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

Окна универсальных приложений (modern UI)

Очень здорово, что они себя стали вести себя как обычные окна: изменяться в размерах, перемещаться, сворачиваться, разворачиваться.

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

Функция SnapView

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

Функция TaskView

Еще одна замечательная функция. И добавить нечего- за-ме-ча-тель-но.

Вывод

Большая работа была проделана "под капотом", в невидимой пользователю части ОС. А то, что видно- вполне достойно того, чтобы обновится до "десятки": и плитки слегка "усмирили", и SnapView с TaskView добавили, и "радость гика"- виртуальные рабочие столы теперь официально поддерживать будут.

При обновлении с "семерки" глаз будет резать "новшества" в меню "Пуск", но это совершенно терпимо. Зато остальные "плюшки"- ваши.

Некоторые соображения о модульных смартфонах

Я хочу поговорить о проекте "Ara" от компании "Google":
http://www.projectara.com/
https://phonebloks.com/en
Google раскрыл подробности о своих революционных модульных смартфонах
Идея сама по себе заманчива: покупаете базу и на нее навешиваете доп. оборудование. Т.е. можно собрать смартфон под себя: по деньгам и по потребностям. Но за красотой идеи видны некоторые существенные проблемы:

1. Снижение прочности корпуса. Если уронить телефон, то из-за обилия подвижных частей что-то отсоединится и перестанет работать (это непременно произойдет согласно закону Мерфи). А то и просто телефон разлетится на мелкие модули по всем углам.
2. Каждый модуль будет иметь свой корпус. Как результат- увеличение размера смартфона из-за толщин корпусов модулей.
3. Не совсем понятно, как можно будет обеспечить привлекательный внешний вид, чтобы наружу не торчали стыки модулей. Если использовать чехлы/крышечки, то у них должны быть отверстия для кнопок. Т.к. телефон модульный, то кнопки пользователь может расположить в любом месте, где ему удобно. Выход: разве что делать на внутренней стороне крышечки перфорацию, чтобы пользователь сам выламывал отверстия в ней в нужном месте.
4. Наверное и цена возрастет, ведь в данном случае невозможно будет удешевить конструкцию за счет интеграции всего функционала в одном чипе.

В общем, будем следить за развитием проекта- уж больно точно он попадает в поговорку "и хочется, и колется".

Планирование разработки

Типичный сценарий из жизни программиста: свои пожелания пользователь излагает последовательно, по мере осваивания нового функционала. В стиле “…А еще бы хотелось…” и далее новый список “хотелок”. Это широко распространенная практика, когда требовать с пользователя техническое задание бесполезно.

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

• “Латать” текущую архитектуру “заплатками”, да “подпирать костылями”, чтобы как можно быстрее выполнить задание. Это понравится пользователю, но код превратиться в “лапшу” и с ним станет невозможно работать.
• Переделать архитектуру, чтобы она соответствовала возросшим требованиям пользователя. Это хорошо для развития программы, но пользователь будет недоволен медленными темпами работ.

Другой вариант: заранее продумывать возможные направления развития программы и  закладывать в архитектуру максимальные возможности. И тут тоже программист сталкивается с неприятностями:

• Если изначально делать “по уму”, то это долго и пользователь будет недоволен.
• Более того, окажется, что 90% возможностей, заложенных в новую архитектуру, останутся невостребованными.

Спасение есть! И оно под боком. Наверняка читатель слышал такое высказывание: “Думай глобально, действуй локально”. Соблюдение этого принципа помогает избежать описанных сложностей. Как это выглядит на практике?

1. Надо описать задачу “максимум” и сделать набросок соответствующей идеальной архитектуры программы. Это то, к чему надо будет стремиться постоянно.
2. При написании каждого класса, функции представлять себе какое место она займет в той “воображаемой” архитектуре программы.

Т.е., программируя для пользователя текущую небольшую задачу, надо структуру кода выстраивать так, чтобы он бесшовно лег на скелет вашей идеальной архитектуры. Одна функция за другой и вот у вас уже на скелет “наросло мясо кода”. Если все функции выполнены были “с прицелом” на будущую архитектуру, то заставить работать их вместе не составит труда.

В результате:

1. Пользователь получает новый функционал быстро и остается доволен.
2. Архитектура программы не рассыпается.
3. Возникает синергетический эффект при стыковке различного функционала, изначально разрозненно разработанного. Т.е. открываются новые возможности использования программы.
4. В любой момент времени программа остается работающей, т.к. в ней не требуется проводить глобальных переделок. Вы всегда можете быстро выдать пользователю новый функционал, а не оправдываться в том, что вы затеяли большие переделки.

Вот и получается: “Думай глобально, а действуй локально.”

Об аналитиках

Android

Давным-давно, на заре 2000-х годов я прочитал статью какого-то зарубежного аналитика. Как раз MS запустила Live search, и вступила на поле деятельности Google. Аналитик говорил, что конкуренция между ними неизбежна и Google должна будет проникнуть на десктопы. В те времена было тотальное засилье ОС семейства Windows, и о таком даже глупо было думать. По крайней мере, мне так казалось.

Аналитик, понимая эту ситуацию, предложил Google выпустить ОС для КПК. Закрепиться, и уже с КПК проникать на десктопы. Не знаю, почему я запомнил именно этот прогноз. Прошло примерно 10 лет с тех пор, и что же мы видим?

В статье “В России Android стал популярнее Windows XP” по графику четко видно, что Android не просто догнал Windows XP, а еще у него динамика роста существенно выше, чем у Windows 7. В конце еще приписочка: “…осенний релиз Android 5.0… будет ориентирован именно на завоевание сегмента ноутбуков.” Т.е. ситуация развивается так, как предсказал тот аналитик.

Действительно, ведь уже и десктопами на Android не удивишь- много выпущено моделей. Похоже, для ОС Windows это уже реальная проблема. А кто бы мог подумать об этом 10 лет назад?

Skype

В те же далекие времена вышла первая версия Skype. Я помню, какой фурор был вокруг этой программы. И я, сидя на постоянно рвущейся модемной линии, удивлялся всем этим восторгам. Skype даже на распрекрасном модеме в 56Кб еле работал- какие там у него могут быть перспективы? Мучение же одно! Прошло 10 лет и Skype, действительно, стал очень популярным.

Заключение

С тех пор прогнозы и то, что вышло в результате у меня вызывает пристальный интерес. В этом блоге публиковались неоднократно прогнозы. Например: Будь в тренде!- это прогноз от IBM. И, кстати, он уже начинает сбываться. Читали Hadoop as a Service? То-то же.

Полный P&P

Пятого октября прошла конференция Microsoft Patterns and Practices Summit Russia 2012 для архитекторов программных систем и руководителей. Докладчики были из Редмонда, из группы “Patterns and Practices”, и из российского офиса компании.

Я сначала распланировал посещение секций так, чтобы по Windows 8 больше информации получить, но потом понял, что наши “евангелисты” от MS больше, чем я уже знаю, не скажут. Быстро переориентировался- и, вуаля- выудил кое-что полезное из выступлений.

Первое. Запомнилось (даже записал и хочу поиграться с этим) организация вложенных вызовов в линейную цепочку: start(a).then(b).then(c).done;. Вместо

if (a(b(c))) { done; },

где a, b, c- могут быть анонимные функции.

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

Второе. В Window 8 в ресурсы приложения одну и ту же картинку можно будет записать с разным разрешением и размером. ОС сама будет вытаскивать и отображать ту из картинок, которая наиболее подходит для данного монитора (с учетом его размеров и разрешения).

Третье. Какую они удобную локализацию сделали- закачаешься! Может это и раньше было, я про это на конференции узнал. Просто создаете папочки вида “en-en”, “ru-ru” и т.д. и кладете туда файлы с ресурсами в которых пишите что-то вроде:

button1.name = …

button.width = …

button.font.style = …

Еще к этому верификацию прикрутить, чтобы проверять к каким текстам, заголовкам сделаны переводы, а к каким- нет, то вообще “бомба”.

Четвертое. Мысль вроде простая, но я нигде (Word, Visio, AutoCAD и т.д.) пока не видел реализации. Зачем на мелком масштабе пытаться отрисовывать маленькие элементы? Там же ничего уже не разглядеть. Куда эффективней заменять изображение более крупными информационными блоками с большими подписями. Ткнул в блок мышкой- масштаб увеличился, блок “раскрылся”.

И еще. Явно об этом нигде не говорится- народ только по форумам судачит. Но я лично на конференции почувствовал, что предпочтение отдается JavaScript. C# вроде как не задвигают, то существенно меньше о нем говорят. Неужто опять будет эпопея с очередной сменой мейнстримового языка? Так что я предупредил- а вы держите “ушки востро”.

Потом, конечно, Вы сами сможете посмотреть выступления на www.techdays.ru, но я вам скажу, что через экран монитора вы упустите “ауру” тусовки- на уровне эмоций, жестов очень многое передается. А это редко в кадр попадает, а если и попадает, то как-то “не ловится” мозгом. Ну, и приятно иногда взять докладчика “за пуговичку” и из “первых уст” получить информацию.

По организации конференции:

1. Очень понравилось. Хорошо все продумано, четко сработано- ну, просто мастера.
2. Для уровня архитекторов программных систем откровенно слабовато. Хотя, судя по уровню вопросов из зала, может это я слишком многого хочу.

Полет мысли в золотой клетке компании

По мотивам статьи “Today is Goof Off at Work Day” у меня родилось несколько комментариев.

Сама статья об известной “фишке” ряда компаний, когда сотрудникам официально выделяется рабочее время для занятий чем угодно. В Google, например, это 20% рабочего времени (соответствует одному рабочему дню в неделю). В Facebook- это “Hack Day”. Из таких “занятий чему угодно” родились известные нам GMail, Google News, Google Talk, AdSense.

Идея выглядит симпатично:

1. Компании такие “day off” могут записать себе в бенефиты, привлекательные для сотрудников.
2. Для компаний это не прямые расходы, вполне себе могут позволить.
3. Если идея хорошая, то у компании есть полные права на ее реализацию и раскрутку. Даже если идея не по профилю компании- тоже сгодится: бизнес диверсифицировать или красиво упаковать и продать реализацию идеи.
4. Работнику хорошо, что мозги можно переключить с одной деятельности на другую. Эдакий активный отдых.
5. Если идея сработает, то работник, наверняка, получит какие-либо бонусы (деньги, должность, репутация).
6. Такие дни “вольного творчества” сродни стартапу. Только в стартапе риски выше. А тут вы ничем не рискуете- за ту же зарплату “стартапите”. Можно возразить, что компания заберет у вас идею, а вам премию в качестве подачки выпишут и все. Но это уже вопрос “синицы или журавля”.

Интересно, если эту идею сделать повсеместной, внедрить на большинстве предприятий, что получится: “вселенский” бардак или мир станет разнообразнее и интереснее?

Будь в тренде!

Очень интересный документ от IBM недавно я нашел и изучил: “Global Technology Outlook 2011”. Известный факт: IBMовские прогнозы не раз сбывались. Этот прогноз меня заинтересовал тем, что он во многом пересекается с моими ощущениями по отрасли.

Социальные сети + Бизнес (Enterprise)

Агрегация, обработка, упорядочивание неструктурированной информации из разных источников. Сюда еще добавляется такой источник информации, как социальные сети. Это позволит улучшить взаимодействие с потребителями, делать “тонкую” подстройку под их потребности.

В этом свете очень интересна экспериментальная социальная сеть от Microsoft. Ее принцип действия: делается поиск нужной информации, и тут же можно найденное опубликовать у себя в ленте и дать к ссылке комментарий. Похоже, MS изучает возможность влияния соц. сети на результаты поиска.

До этого Google пыталась запустить новый поисковый алгоритм, рассчитывающий релевантность ссылки по ее популярности в соц.сетях.

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

Увеличение объемов обрабатываемой информации

С одной стороны- в этом нет ничего удивительного, но с другой- посмотрите, какие цифры они приводят.

В этой связи ожидается большой спрос на DaaS (Data-as-a-Service), AaaS (Analytics-as-a-Service). Подозреваю, что на этом рынке могут “играть” только крупные игроки. Тем не менее, у небольших стартапов есть шанс разработать/оптимизировать процесс обработки данных и продать разработку “крупняку”.

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

Логика приводится “железная”. Но я в этой области не “спец”, чтобы комментировать. Почитайте и подумайте сами.

Интернет вещей

Про интернет в каждом электрочайнике и кофемолке, я думаю, каждый слышал? Об этом много и давно говорится. Я еще в 2000 году сделал свою разработку на эту тему, выступал на студенческих конференциях с этой темой. Совсем недавно от Microsoft просочились новости об ОС, предназначенной для управления домашней бытовой техникой.

Возможностей, конечно, тут открывается немало. Но тема настолько вялая, что, я не верю, что в ближайшее десятилетие она “выстрелит”. Хотя, конечно, всей душой за более быстрое развитие этой темы.

Обучающиеся системы

Ну, кто бы сомневался! Это очевидный, сильный тренд, довольно таки “старый” уже. Если тему “обучающиеся системы” скрестить с темой “Социальные сети + Бизнес (Enterprise)” (работа с неупорядоченными данными), то получим взрывное (для мозга) направление работы.

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

Итоги

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

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

Если вы не IBM’еры, то можно порекомендовать заниматься:

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

Это могут быть алгоритмы сортировки, распараллеливания вычислений, извлечения ключевых слов, понимание контекста, распознавание образов и т.п. Очень хорошие, интересные, перспективные темы. Дерзайте!

Советы программистам-новичкам. Настройка на работу

Как я уже ранее говорил, в работе программиста есть творческая часть. Это приводит к некоторой проблеме. Например, слесарь может точить детали хоть трезвый, хоть “с бодуна”- руки-то “помнят” и “на автомате” будут строгать детали. С творчеством так не бывает- муза капризна и когда “накроет” не угадаешь. А работать-то надо. Одна из черт профи- стабильная работоспособность.

Поэтому, надо учиться управлять своим состоянием. Отличный материал на эту тему в статье Джоэля Спольски. Для себя я выработал такой подход. Всю мелочевку я сразу не исправляю- оставляю “на потом”. Если у меня получилось по-джоэлевски попасть в состояние потока, то я берусь делать что-то большое и сложное. Когда состояние потока проходит, то берусь делать как раз те мелочевки, которые специально откладываю для таких периодов работы, когда творческий запал угасает. Это позволяет мне равномерно “размазать” работу, заполняя рутиной пустоты между творческими пиками.

Советы программистам-новичкам. Не твое- не трогай!

Есть такой старый армейский принцип: “Не твое- не трогай.” Этот принцип верен и в отношении программирования в команде. Делай свой кусок работы, и не меняй что-либо в чужом коде. В чем смысл данного правила?

Например, вы поменяли, буквально, чуточку в чужом коде, т.к. заметили в нём ошибку (на ваш взгляд ошибку). Проверили тут же- работает. Выложили код. И тут оказывается, что старик Мерфи прав. Ту части кода, которую вы “осознали” и подумали, что это ошибка, вы-то исправили. А вот оказывается, что ваше исправление поломало функционал в куче других мест, о которых вы и не подозревали.

Как же быть тогда? Надо узнавать ответственного за этот код. Лучше всего, конечно, лично подойти и решить вопрос. Если это невозможно, то “кинуть” ему в трекер багу. Если изменения надо внести срочно, то можно и самим это сделать, но обязательно надо в трекер на соответствующего ответственного разработчика кинуть описание этого бага с описанием тех изменений, которые внесли вы. Попросить при этом разработчика проверить, допустимо ли так делать. При выкладке кода в репозиторий надо в комментариях указать номер вашей заявки в трекере.

Таким образом, если вы ошиблись, и ваши изменения неправильны, то ответственный разработчик быстро разберется что к чему и поправит. Даже если по времени это произойдет не скоро, то, все равно, ваша “задница” прикрыта- вы сделали все, зависящее от вас.

Из  этого правила есть следствие: не меняй ничего в чужих строчках кода. Даже если это всего лишь вопрос форматирования кода. Даже лишний “пробельчик”. Ничего. Если будут выяснять, после какого коммита поломался код, то будет видно, что эта строчка кода записана за вами. Вот потом и будете вспоминать и доказывать: “А я там всего лишь “пробельчик” для красоты поставил.” Зачем вам это? Еще раз:

“Не твое- не трогай!”

Советы программистам-новичкам. Не умничай

Это распространено не только в среде программистов- от любого мастера (парикмахера, сантехника, строителя) можно услышать фразу: “Да кто же так делает! Это все неправильно…” В отношении программистов эта фраза дополняется восклицанием: “Это все надо переписать! Я сейчас это сделаю.”

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

Если на ваш ПЕРВЫЙ взгляд вам кажется, что можно было сделать проще/лучше, то помните:

1. Код был написан, скорее всего, несколько лет назад. Для программирования- это не малый срок:
   • Может быть, в те времена было так принято писать.
   • Не было такого API, которым можно было бы сделать все проще.
   • Не было такого синтаксиса, позволяющего выразить мысль компактнее.
2. Вы не знаете обстоятельств, которые сопутствовали его написанию:
   • Просили сделать очень быстро- лишь бы работало.
   • Хотели посмотреть “на попробовать” как будет и нужен был набросок. А потом возникли другие обстоятельства и про код забыли.
   • Изначально было сделано хорошо, а потом код многократно изменялся разными программистами, проповедующими различные подходы к написанию кода, которые еще своего там намешали.
3. Личные обстоятельства:
   • Программист увольнялся- ему было “пофигу”.
   • Не дали премию, мало заплатили.

Ну и, конечно, остаются варианты, относящиеся напрямую к исходной фразе: “Да кто же так делает!”:

1. Мало предлагали денег по вакансии и на работу наняли слабого программиста.
2. Наняли по блату.
3. Наняли умного парня, но большого любителя поэкспериментировать.

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

Советы программистам-новичкам. Инструменты

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

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

Распространите этот принцип на все ваше рабочее место:

1. Хороший компьютер, монитор (а лучше два), удобная мышь и клавиатура.
2. Настройте автоматическое резервирование (потерять время на переустановку системы из-за полетевшего диска- это дорогое удовольствие, дешевле стоит внешний диск для резервирования).
3. Удобный трекер, быстрый репозиторий, хорошую “мержалку” бранчей.
4. При программировании используйте хорошие библиотеки, системы сборки.

Это на первый взгляд кажется очевидно, а на практике постоянно приходится сталкиваться с тотальным использованием отстойного инструментария. И это сказывается на результатах.

Не берите тот инструмент, который проще всего достать, который под рукой- ищите лучший. Простой пример: MS XML есть в каждой ОС, и, поэтому, его очень просто начать использовать. А если померять скорость работы этой библиотеки, то обнаружите, что она примерно в два раза медленней работает большинства других библиотек. Может для простых “конфигов” это и не важно, но если надо читать файлы в несколько мегабайт, то здорово с MS XML намучаетесь.

ASP.Net vs Python ;)

Я об этой статье: “Linux, или туда и обратно”. Как-то так совпало с моей ситуацией. Просто расскажу в добавок к ссылке свою историю, без выводов- вы их сами делайте.

Мне нужно было написать мааааленький web-сервис. Бесплатно- не хочу платить деньги за вещь, которая мне никогда денег не принесет. Я выбрал Google AppEngine и стал писать на Python. Я столкнулся с тем, что немало времени занял разбор документации и установка среды разработки (Eclipse). Но это ерунда. Потом каждая строка кода стоила по времени очень дорого. Буквально каждая строка “сопротивлялась” и “не хотела работать”. Я копался в доках, спрашивал по форумам, лазал по исходникам. Чай, умения мне в этом не занимать- за плечами 15-летний опыт программирования. Делал по вечерам, неспешно… И так прошел ГОД.

Потом я у видел у godaddy.com бесплатный хостинг ASP.Net, очень скромный по характеристикам, но мне хватит. Для меня ASP.Net такая же “темная лошадка”, что и Python- я никогда не программировал ни в Eclipse на Python, ни в VS на ASP.Net. Но я решил попробовать. И тут случилось УДИВИТЕЛЬНОЕ. То, что я писал на Python для Google AppEngine год, я написал в бесплатной Visual Studio Express 2010 на ASP.Net за… ОДИН ВЕЧЕР.

Мне очень помогало, то что студия быстро установилась и без каких-либо настроек можно было приступать к работе. Хорошая среда разработки- “автокомплит”, мощный отладчик, а также развесистый фреймворк. Может, это как-то помогло столь разительно быстрее достичь результата на ASP.Net, чем на Python… а может и нет- выводы сами делайте.

Заметки о форуме Microsoft Innovation Day 2011

Ссылка на сайт форума: http://www.microsoft.com/ru/ru/isv/forum/innovationday.aspx.

Форум состоял из двух частей: для технарей и для руководителей. Подробности, видео смотрите на сайте. Я по пунктам перечислю свое ощущение от увиденного.

1. Очень интересно свел вместе разнородные данные выступающий от IDC. Привел график по численности населения- видно, что в перестроечные времена рождаемость резко упала (“на глазок”- раза в два). Теперь это поколение подросло, и к 2020 году должно заменить на рынке труда уходящее на пенсию старшее поколение. Вот и получается, что, фактически, не кем заменять будущих пенсионеров! Кадры станут дефицитным и, видимо, дорогим ресурсом. Следующий график- рост численности серверов. Их надо кому-то обслуживать- а не кому! Т.е. проблема высококвалифицированных кадров к 2020 году будет просто “аховая”: потребности растут, а специалистов становится все меньше и меньше. Понимаете теперь почему хотят поднять пенсионный возраст в правительстве? Но меня, как программиста, этот доклад успокоил: цена моей работы возрастет, и работы будет много.
2. Оказывается по данным NIST их MS SQL Server является самым безопасным: SQL Server- 49 уязвимостей; Oracle- ~300 уязвимостей; DB2-121; MySQL- 98. За последние 6 месяцев уязвимостей не найдено вообще. Вау! NIST- это вам “не хухры-мухры”. Уважаю.
3. Один из недостатков “облаков”- это привязка софта к конкретному “облаку”. Перепрыгнуть в другое “облако” очень тяжело. Ситуация, как бы, выгодная для Microsoft. Но, тем не менее, Дмитрий Мартынов поднял тему миграции между “облаками”, а также обратной миграции из “облака” к клиент-серверу или локальному решению. Удивила такая готовность предложить обратную миграцию.
4. Не знал про Azure, что их “облако” умеет работать в 3 режимах. Можно вообще образ системы залить, и он там будет “раскатываться” по серверам. Т.е., реально, можно любое ПО таким образом в “облако” засунуть. Грубо, но можно. Молодцы, круто сделали. И про миграцию подумали, и про обратную миграцию. С ходу и не подкопаешься.
5. Миграция- то ладно, а вот непривычно было, что сотрудники Microsoft не только хвалят, но и про недостатки своих продуктов говорят. Смело так говорят: “Как было можно сделать…! Я возмущался, пинал их…. Обещают сделать.” В таком духе. А я-то думал, что у них с этим строго- никакого негатива и точка. Это очень хорошо, что про недостатки рассказывают тоже- когда сам, лично, на них напарываешься, то это создает гораздо более сильный негатив, чем если просто послушать про это на форуме.
6. Я привык, что главные докладчики- директора, руководители- после выступления сразу сматываются. А тут, смотрю, Ложечкин сидел всю “пленарку”. Хотя после своего первого 15-минутного доклада мог и уйти. Непривычно.
7. Если на “пленарке” сидели все вместе- и программисты, и руководители, то потом разбились по секциям. И прямо до смешного стала видна разительная разница во внешнем виде. На секции для технарей сидели люди в свитерах, рубашках, брюках, с длинными волосами- свободный стиль одежды. На секции для руководителей народ сидел в пиджаках, при галстуках, весь из себя чинный- формальнее некуда.

В целом, все, о чем говорили докладчики, давно уже опубликовано. Как источник информации форум скучен, не интересен и бесполезен. Но вот там, в программке есть последний пунктик: фуршет на 1,5 часа. Это неформальное общение, заведение знакомств. Т.е., как одну из задач форума, можно указать стимулирование создания и поддержания экосистемы вокруг продуктов компании. Чтобы люди встречались, обсуждали, знакомились, сотрудничали, чтобы их сотрудничество порождало синергетических эффект, усиливающий экосистему вокруг продуктов Microsoft. Наверное как-то так. А еще, это информационный повод, чтобы о Microsoft писали СМИ. С этих позиций организация форума имеет смысл.

К вопросу о классификации ПО

Речь о двух крупных группах- проприетарное ПО и СПО. Оба термина мне активно не нравятся. На уровне подсознания я чувствую в них корявость. Если попытаться озвучить, что именно не так названиями, то получится примерно следующее…

В технике давно уже сложилось соответствующее деление изделий по исполнению: коммерческое, промышленное, военное. Есть еще деление по климатическим зонам. А есть еще носимая техника, переносная, стационарная. Т.е., это все- классификации самого изделия. В то время как СПО и проприетарное- это характеристика условий использования ПО (условий лицензирования). Т.е. к самому продукту это отношения не имеет. Поэтому слово “свободное” не имеет права находится рядом с фразой “программное обеспечение”, также как и “проприетарное”. Распространение ПО давно уже никто не ограничивает. Я как-то купил журнал “Вокруг света”, и в нем был диск в MS Office 2007. Пожалуйста, устанавливайте сколько угодно, пользуйтесь 60 дней бесплатно. Понравилось- платите, иначе- удаляйте. Т.е., получается что MS Office, как продукт, как набор битов, записанных на носитель, распространяется свободно. А вот лицензий на него множество: для школ, для журналистов, писателей, стартапов, крупных предприятий, работников крупных предприятий, простых индивидуальных покупателей- для каждого можно подобрать лицензию. Лицензию на один и тот же набор свободно распространяемых битов.

Почему важно “отделить мух от котлет”: ПО от условий его использования, четко определить терминологию и правильно классифицировать продукт? Вот, например, последняя, актуальная тема “Национальная программная платформа” (НПП). В документах официально пишется термин СПО. При этом всем ясно, что речь только о Linux. Но ведь это неверно! Под термином СПО может быть и MS Windows и Mac OS- вопрос в том, по какой лицензий они будут предоставлять свое ПО для участников программы НПП. А Microsoft на недавней сделке с Газпромом показала очень высокую гибкость, предоставив им особые условия лицензирования и скидку в 70%. Кроме того, компания давно уже открывает исходные коды гос.органам, крупным своим партнерам. Более того, компания раздает кучу ПО бесплатно. И Windows, и Office уже давно распространяются на принципу shareware. Да Microsoft СПОшнее, чем ALTLinux с Madriva’ой вместе взятые! Может быть, в НПП надо определять типовую лицензию, допуская к участию тех, кто предоставляет свое ПО, которое, помимо других требований, можно будет использовать в соответствии с типовой лицензией НПП?

А то получается, что неправильно подобранная, и своеобразно трактуемая терминология отсекает от участия в программе огромный пласт высококлассного ПО! Более того, давайте посмотрим, что же на самом деле остается в рамках придуманного термина СПО. Ведь так или иначе, речь идет именно о Linux и стеке технологий на базе этой платформы. Если отказаться от словосочетания СПО, то как это все назвать? “Все”- это сам стек технологий, доступность исходных кодов, возможность бесплатной установки и использования и т.п.- то, что большинство специалистов как раз и понимает под сокращением СПО. Повторяю. Исходная задача: терминология, классификация.

Придумывать новую терминологию без необходимости не надо, тем более, что в данном случае нам хватит существующих терминов. Давайте взглянем на мир Linux. Независимые разработчики, как их называют, пишут код. Вечером, сами для себя, для фана- это хобби. Как есть люди, которые любят копаться допоздна с машиной, или увлекаются радиоспортом, или ходят регулярно на футбол- поиграть с приятелями, с такими же увлеченными, как и они людьми. Так и программисты есть, для которых хобби- программирование. Он написал программу- поделился с другим. Другой что-то еще дописал. Третий сказал: “Ерунда!” А ему в ответ: “Вот код- сделай как тебе надо!” Кто все эти люди? Это ЛЮБИТЕЛИ! Радиолюбители, автолюбители, книголюбы, фанаты- все эти люди в свое свободное время делают то, что им нравится. То, что они делают, называют любительскими поделками: “Я захотел и сделал, а если тебе не понравилось, то на- переделай или сделай свое. Мне и так нравится.” Ведь именно так сторонники СПО говорят!

Верные и очень точные термины: программисты-любители и любительское программное обеспечение. Отсюда и классификация ПО “автоматом” выплывает: любительское ПО, профессиональное ПО. Старые, добрые термины, понятная классификация.

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

И вот тут две неприятности для любительского ПО всплывают.

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

“Про это распоряжение узнал месяц назад, когда нас озадачили составить список ВСЕГО софта, используемого у нас и в филиалах. А сегодня все-таки решил поподробнее изучить цену вопроса.
В итоге нашел, что это СПО будет обходиться намного дороже MS.
Цена лицензии "0 руб.", но ОБЯЗАТЕЛЬНАЯ поддержка на каждое устройство (сервер или рабочую станцию) будет обходиться от 2 до 24 тыс. руб. в год!!! Таков порядок лицензирования.
При всем этом, срок решения вопросов поддержки от 2 до 10 дней, при условии, что ее удается решить в этот срок, в противном случае проблема "признается нерешаемой"... и как дальше поступать пользователю - тишина.
Все сведения взяты с официальных источников:
http://tp-npp.ru/ - Координатор технологической платформы ОАО "Концерн "Сириус" (Государственная корпорация "Ростехнологии")
http://www.altlinux.ru/ - основной поставщик СПО госорганам
http://www.altlinux.ru/fileadmin/prod..._tp_01.pdf - Купон технической поддержки.“

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

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

В итоге:

1. Предлагаю использовать терминологию любительское/профессиональное ПО вместо свободное/проприетарное ПО.

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

Агентство "Мы ищем таланты"

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

Зачем это нужно?

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

Почему это надо делать?

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

Как это сделать?

1. Сформировать пул потенциальных инвесторов. Например, гранты на исследования уже выдаются компанией Microsoft. Выразили заинтересованность в сотрудничестве с фондом многие крупные компании. Такая работа уже проводится- с “нуля” делать ничего не придется.
2. В ВУЗами фонд подписаны меморандумы о сотрудничестве. В рамках этих меморандумов следует договориться о получении в электронном виде тезисов докладов с научных конференций. Тут же можно подумать о формировании базы данных и публикации на сайте фонда этих тезисов, чтобы инвесторы могли сами “попастись” на сайте в поиске интересных идей. Это будет способствовать созданию комьюнити вокруг фонда.
3. Доклады могут делаться как самими учеными, так и студентами, у которых ученый является руководителем проекта. Интересные с точки зрения доклады отбирать для более детального анализа.
4. По отобранным докладам провести детальный анализ (включая выезд к ученому и устное обсуждение деталей), подготовив аналитический отчет. В отчете отразить степень готовности исследования к коммерциализации и примерную область применения.
5. Из пула инвесторов выбрать потенциально заинтересованных, которым предложить выделить грант на исследование с последующей коммерциализацией. Фонд может выступать как соинвестор.
6. Антрепренёр, т.е. человек который нашел ученого, свел его с инвестором и добился инвестирования получает вознаграждение.

Достоинства моего предложения

1. Данный механизм отлично “ложится” на деятельность фонда и укладывается в уже существующие договоренности между фондом, ВУЗами, инвесторами.
2. Поиск талантов переходит на качественно новую стадию- он становится активным. Вместо пассивного ожидания, когда сам исследователь со своей разработкой придет в фонд за финансированием, фонд сам его ищет и предлагает ему все готовое. Исследователю останется только подпись в договоре под галочкой поставить и получить деньги на свой счет для исследований. В то время как сейчас он должен проявить “коммерческую жилку”, отвлечься от исследований: зарегистрировать юридическое лицо, найти иностранного участника (требование фонда), подать заявку в фонд и пройти все формальные процедуры оформления.
3. Формирование базы данных исследовательских проектов будет способствовать формированию “Сколковской общины”, создание которой декларируется фондом.
4. Это всем выгодный подход: компании-инвесторы получают информацию по исследованиями, которые могут заинтересовать их R&D подразделения; фонд выполняет свою миссию, существенно наращивая свой портфель проектов, антрепренёр получает свой процент от сделки. Полный “win-win”, как говорится.
5. Сам план прост, и его возможно в течение нескольких месяцев начать реализовывать.

У «Галактики» все получится, вот увидите!

Исходная новость:

«Галактика» атакует SAP, Oracle и Microsoft на уровне модулей

Российский разработчик систем управления предприятием (ERP) «Галактика», ощутив насыщенность рынка, принял решение переориентироваться на разработку прикладных решений. Как рассказал CNews президент «Галактики» Николай Красилов, ERP пока остается основным продуктом, но компания уже разработала решение для управления имуществом, а до конца 2011 г. намерена выпустить еще три продукта: для управления активами предприятия (EAM, enterprise asset management), проектами (PM, project management) и прое… полный текст

Источник: CNews

Теперь ссылка на мою статью: ERP по лицензии GPL: условия выживания и кусок из моей статьи:
“…Это позволит при сборке собственной системы ERP задействовать подсистемы различных производителей и собрать систему под использование с требуемой СУБД. Небольшим производителям систем автоматизации выгодно использовать такую ERP, т.к. они смогут свои системы дополнить недостающими подсистемами или заменить свои менее функциональные подсистемы на аналоги. Вероятно, они (небольшие производители систем автоматизации) станут основными двигателями процесса разработки подобной ERP.
В конечном итоге, система получится очень гибкая, в ней возможно будет комбинировать подсистемы различных производителей, реализуя различный функционал. Таким образом, процесс внедрения будет аналогичен, тому как внедряются коммерческие ERP, с одной стороны.”
Год назад я рассматривал возможность для ERP-систем, выпускаемых по лицензии GPL отхватить некоторую долю рынка ERP-систем у монстров SAP, Oracle и Microsoft. Модульность систем- это был один из пунктов моего плана: “…возможно будет комбинировать подсистемы различных производителей, реализуя различный функционал”.
“Галактика”, похоже, выбрала этот путь развития. Я считаю это удачным решением. Успехов вам, “галактяне”!

Семь основных трендов в развитии программного обеспечения

Интеллект, интерфейс, производительность, кроссплатформенность, “облака”, высокоуровневость, стандартизация - вот основные тренды на протяжении последних нескольких лет, которые проявились и стали набирать силу в развитии ПО. О них неоднократно говорили ведущие специалисты отрасли. Эти тенденции уже явно влияют на ПО, которое используется на сегодняшний день.

Интеллектуальность

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

1. Прогнозирование последующих действий пользователя. Это позволит, например, сформировать подсказку, динамическое меню для того, чтобы у пользователя сразу “под рукой” были весь требуемый инструментарий для работы.
2. Интеллектуальное кэширование данных, обработка звука, изображений.
3. Автосохранение, автобэкапы, версионность файлов- в случае сбоя у пользователя всегда будет под рукой резервный вариант.

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

Пользовательские интерфейсы

Лет десять-пятнадцать назад удобство пользовательского интерфейса не было решающим фактором при выборе ПО. Ценилась больше функциональность. Это было связано с тем, что программы были не столь функциональны, инструментарий программиста был не такой мощный. В результате, программирование одной функции было огромной работой. Если ваше ПО имело на 2-3 функции больше, чем у конкурента, то у вас были большие шансы на успех. Сегодня практически любой функционал легко и быстро повторяется конкурентами. Получить длительное по времени конкурентное преимущество можно, внедрив более интеллектуальный функционал и, как ни удивительно, разработав хороший интерфейс пользователя. Создать удачный интерфейс- это большая работа. Фактически, действительно мощный инструментарий для создания пользовательских интерфейсов начал появляться совсем недавно.
Тенденция создания удобных интерфейсов – очень сильная и явная. Примеров множество- iPhone, Android, лента меню Ribbon от Microsoft. Даже в области корпоративного ПО она будет проявляться все сильнее. Об этом подробнее можете прочитать у Петра Диденко.

Производительность

Ярким примером, иллюстрирующим тему данного абзаца, можно назвать гонку браузеров за производительностью их движков. Разработчики активно оптимизируют операционные системы, различное прикладное ПО. Например, последний MS Office 2010 чувствительно быстрее своего предшественника. Windows 7 шустрее Vista.
У пользователя несколько процессоров, много памяти, графический ускоритель- так почему бы не задействовать это на “полную катушку”? В конечном итоге, быстрый, отзывчивый и удобный интерфейс очень понравится пользователю.
К счастью, в распоряжении разработчика есть ряд удобных инструментов для выявления “узких мест” в программе, поиска утечек памяти и т.п. Ряд известных программистов в интервью не раз упоминали о том, что оптимизация производительности- это тренд, минимум, на ближайшие пять лет. Поэтому, профайлер в зубы, и вперед!

Кроссплатформенность

Платформ опять стало много. iOS, Android, Simbian, Windows Phone, Linux, MS Windows и еще многие другие. Все важные, все занимают существенную долю рынка, чтобы их игнорировать. Разработчики давно уже тяготеют к кроссплатформенным решениям. Программы на C/C++ часто пишут так, что они успешно компилируются под разными платформами. Java, .Net, Python концептуально кроссплатформенные. Обеспечить кроссплатформенность тому или иному алгоритму на сегодняшний не сложно. Но вот интерфейсы… с ними загвоздка. Есть очень неплохие решения, обеспечивающие кроссплатформенность интерфейсов. Например, Qt. Тем не менее, это далеко не идеальные решения.
Громадная каменюка “преткновения” кроется в том, что под разными ОС не только внешний вид разный, но поведение элементов  интерфейса может отличаться. В результате, приходится реализовывать под разные ОС некий усредненный вариант интерфейса. Что не придает приложению ни красоты, ни удобства.
Тогда разработчики приноровились использовать web-интерфейсы даже в исключительно оффлайновых приложениях. Такой способ позволяет снять ряд проблем при создании кроссплатформенных интерфейсов. Все же HTML-страница более-менее сохраняет свой вид в разных ОС, да и функциональность элементов интерфейса тоже будет одинаковая. Но и тут нет совершенства.
И вот, на сцене появляется HTML5. Пока он не распространен широко, но те немногие примеры его использования, что довелось увидеть, впечатляющи. Правда, и тут видны недостатки. Как говорится, предела совершенству нет. Тем не менее- встречайте HTML5! Рассмотрите возможность его использования для организации интерфейсов как онлайновых, так и оффлайновых приложений. Это позволит создавать функциональные, удобные и красивые кроссплатформенные приложения.

Использование технологии облачных вычислений

Web-приложения, инсталлируемое ПО- у каждого типа приложений есть свои достоинства и недостатки. И как всегда хочется получить достоинства обоих типов приложений. С одной стороны, web-приложения позволяют нам просто делать свое дело и не заботиться об установке ПО, о резервных копиях данных- просто залогинился и работай. С другой стороны, инсталлируемое ПО позволяет работать в оффлайновом режиме, задействовать все имеющиеся ресурсы на компьютере. Например, Web-приложение нельзя установить как сервис в ОС. Возможность получить преимущества от обоих типов ПО дают облачные вычисления.
Обратите внимание, что на сегодняшний день под облаками часто понимаются все те же web-приложения, только “размазанные” по сотням серверов. Предлагается расширить использование облаков, задействуя их в полноценном инсталлируемом ПО.
Объединение возможностей инсталлируемых приложений и web-приложений позволит:

1. Организовать автоматическое резервирование данных в “облаке”. Так как данные сохраняются в облаке, то они будут доступны пользователю с любого компьютера. С другой стороны, если отсутствует доступ в Интернет, то можно работать с их локальной копией.
2. Предоставить разные способы доступа к данным: инсталлируемое ПО, web-приложение, доступ с мобильного устройства.
3. Организовать коллективную работу с данными.
4. Переложить заботу о сохранности данных и их постоянной доступности на плечи “облачного” сервиса.
5. Находясь на своем рабочем месте получить полноценное приложение, использующее все возможности компьютера, ОС для плодотворной работы за счет использования инсталлируемого ПО.
6. Получить оперативно удаленный доступ через web-приложение, через мобильное устройство, находясь вне рабочего места.
7. Получить все преимущества “облачной” технологии, связанные с масштабируемостью и отказоустойчивостью “облаков”.

Высокоуровневость

На сегодняшний день в низкоуровневом программировании, практически, не осталось “ноу-хау”. Работа с USB, камерой, видео, звук, дисковые операции- это умеет делать хорошо любая ОС. Преимущества тут уже давно нет ни у одной ОС. Если подниматься на более высокие уровни кода, то можно заметить, что даже набор прикладного ПО, идущего в составе ОС уж давно не уникален. Ну на какой ОС нет аналога Блокнота, Калькулятора, Paint’a?  Разве что Apple можно “пнуть” за отсутствие “флэша”, и то- это умышленный ход.
Потребителя теперь завоевывают сложными, высокоуровневыми приложениями: распознавание голоса (например, голосовой поиск от Google), распознавание изображений (лиц на фотографиях- Picasa, Windows Live), рукописного текста (Windows 7), фильтрация спама (Gmail), распознавание движений (Kinnect), поисковые технологии (Google, Yandex). И тут поле деятельности весьма широкое: эти технологии, с одной стороны, на более качественном уровне решают проблемы человеко-машинного интерфейса, с другой стороны, сложны в воспроизведении конкурентами, что дает достаточно времени для “снятия сливок” с рынка. Наделение коммерческого ПО элементами искусственного интеллекта- тема еще свежая, “мало раскопанная”, поэтому тут есть, где развернуться, есть интерес со стороны потребителей, есть деньги.
Можно констатировать, что обладание своими низкоуровневыми технологиями на сегодняшний день- недостаток. Ведь на поддержку и развитие их надо тратить время и деньги. При этом, конкурентных преимуществ никаких. С другой стороны- высокоуровневое программирование с новыми перспективами, денежными рынками.
Как бы смело это ни звучало сейчас, но со стороны той же Microsoft было бы разумным перейти на использование наработок сообщества open source. Например, как это сделала Apple, Google. Google, вообще, очень эффективно использует наработки open source: и Linux, и Python, и web-приложения. Еще пример: Intel, Nokia с MeeGo.
Из антипримеров: Windows phone 7. Огромные усилия затрачены на ее разработку с нуля. В результате, этой ОС надо еще 1-2 года, чтобы довести ее до конкурентоспособного состояния. Думаю, что если бы они пошли по пути Google, и использовали ядро Linux, чтобы создать свою ОС для смартфонов, то это у них бы заняло существенно меньше времени и результат был бы лучше.
Времена меняются. Сейчас надо использовать шире уже наработанные решения, придерживаться стандартов и создавать высокоуровневое ПО.

Стандартизация

Как всегда это бывает, на заре любой отрасли существуют различные не совместимые решения, все сумбурно и знания быстро устаревают. Потом все “устаканивается”, появляются отраслевые стандарты и с полученными знаниями, опытом специалист может спокойно прожить всю жизнь, не боясь, что он завтра станет никому не нужен из-за того, что его знания устарели.
Аналогичная картина развития отрасли наблюдается и в ИТ. Все больший приоритет приобретают стандарты при проектировании ПО. Формируются приемы программирования (например, см. GoF), накатываются методики ведения проектов. Хотя проблема быстрого устаревания знании еще актуальна, но она уже явно менее остра, чем 20 лет назад. ИТ стабилизируются в своем развитии, выходят на плоское плато S-образной кривой развития. Это замечательно. Так и должно быть.
Свое стремление соблюдать стандарты, подтверждая это делами, демонстрирует даже какой яркий нарушитель стандартов как Microsoft. Эта тенденция видна повсеместно и касается всего: пользовательских интерфейсов, протоколов обмена данными, форматов хранения данных и т.д.

Вывод

Перечисленные семь наблюдаемых в последние годы тенденций: интеллект, интерфейс, производительность, кроссплатформенность, “облака”, высокоуровневость, стандартизация характеризуются устойчивым, сильным трендом. Нет оснований полагать, что в ближайшие минимум пять лет произойдет смена этих тенденций другими.
Правильным путем развития программных продуктов будет следование этим тенденциям в той или иной степени. Например, можно пойти по пути улучшения пользовательского интерфейса, или добавить интеллекта в свое ПО, или сделать одновременно и то и другое.
Какой бы Вы путь ни выбрали из перечисленных пунктов, помните, что в конечном итоге “видеть” надо человека, пользователя вашего продукта. Эти тенденции- только направление движения к решению проблем пользователя, а какую именно дорожку выберете Вы- это и есть Ваш элемент творчества, который не отнимут у вас никакие стандарты, никакое плато. Так что, дерзайте!

Будущее начинается сегодня

В своей статье "Грезы о будущем сквозь дым пожаров" я писал о перспективных направлениях разработки. А теперь прочтите эту новость: "Microsoft покупает компанию Canesta". Сравните, чем занимается компания Canesta с тем, что я описал в пункте "Пример первый" моей статьи.
То, что я- непризнанный пророк :*) , чьи прогнозы уже многократно сбывались, я скромно умолчу. Акцентирую внимание на то, что те примеры ПРАВИЛЬНОГО направления развития, которые я показал в моей статье- это не отдаленная фантастика. Это- реальность. Это- уже здесь.

Если вам мои примеры из статьи кажутся слишком абстрактными, то я создал сайт "Идеи для стартапов" с описанием конкретных, практичных идей. Эти ПРАВИЛЬНЫЕ идеи, укладывающиеся в общемировые тренды развития ИТ-технологий, раздаются БЕСПЛАТНО. Пожалуйста, берите их, реализуйте. Если вам нужны деньги на реализацию- смело с этими идеями идите к инвесторам. Как минимум, эти идеи не хуже других идей, которые выслушивают инвесторы регулярно.

Работа в команде

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

1. "Не лезь в чужой монастырь со своим уставом." Если в проекте используются коды ошибок, а не исключения (exception), то используйте коды ошибок- "брезгливо морщить носик" не надо. Соблюдайте code guide. Это очень просто- смотрите на соседний код и делайте так же.
2. При возникновении спорных ситуации или выяснения кто виноват, не становитесь в непримеримую позу "у меня все ОК, это вы- козлы, ищите ошибку в своем коде". Давайте слабину: "Может быть и мое, давайте вместе попробуем воспроизвести баг. Если он мой, я его, конечно же, устраню." Если баг действительно окажется ваш, то вы ничего не теряете. Но вот, если вы от него отмахнулись, а баг таки оказался вашим, то вы "теряете лицо".
3. Неформальное общение. Даже если вы не общительны, все равно принимайте участие в организации "корпоративов", ходите на обед с коллегами и т.д.
4. Используйте защитное программирование. Когда код пишут разные люди, то гарантировать единообразное использование кода невозможно. Наверняка найдется рано или поздно кто-то, кто вызовет вашу процедуру с недопустимыми параметрами. Программа "упадет" и call stack покажет на нутро вами написанного класса. Да, в конечном итоге вы разберетесь, что, например, кто-то тупо забыл создать класс перед его использованием, и перенаправите баг кому надо, но время на выяснение этого потеряете. Конечно, далеко не все можно проконтролировать, но вот проверить корректность входных параметров, возвращаемых параметров из других функций можно. Давным давно, я помню, как работал в команде, в которой был один замечательный программист. Программировал он очень быстро, но крайне неаккуратно. Его код постоянно падал и глючил. Я программировал медленее, но мой код был надежнее и безглючнее. Пока тот программист с "высунутым языком" бегал и правил свои баги, я неторопливо "серфил" в интернете, т.к. мое все работало. Со временем наши подсистемы сильнее интегрировались друг с другом, и мои процедуры стали падать из-за его кода. Его головная боль стала и моей. Пользователи кидали мне баги пачками. Тогда я стал проверять все входные параметры и выходные параметры вызываемых в моем коде функций. Проверял, буквально, маниакально. Даже самые очевидные вещи (например, id>0). Кидал ошибку с пояснениями. Это помогло быстрее выяснять причину бага и аргументированно перекидывать его на другого. Это не сложно, прекрасно для этого подходят Assertion.
5. Жесткий каркас архитектуры. Это сделать очень сложно- надо быть невероятным ассом, чтобы получилось так. Но оно того стоит. Речь о том, чтобы спроектировать архитектуру подсистемы так, чтобы сама структура препятствовала ее неправильному использованию, и даже более того- изменению в архитектуре! Если "перегнуть палку" в проектировании жесткого каркаса, то получиться не масштабируемая архитектура, что тоже плохо. Даже использование паттернов тут не всегда помогает- всегда найдется программист, который, например, попытается "пролезть" за фасад (имеется ввиду соответ. паттерн), чтобы получить напрямую доступ к скрытым за фасадом классам. Как? Да, например, через глобальную переменную! О, ужас, ужас! Но это жизнь, и так бывает (лично сталкивался). Как можно от этого защититься? Но, только, чтоб это была не просто защита, а и достаточно полезная функция или "фича" архитектуры. Можно использовать отложенное создание класса, находящегося за фасадом (по первому обращению к нему), сам класс генерировать из фабрики и удалять его, если к нему долго не обращались (т.е. за фасадом основное время ничего нет- никакого класса). В этом решении мы экономим память, увеличиваем скорость загрузки приложения. Да и к тому же "портим карму" тому "плохому" программисту. Он то, наверняка, либо в коде не разберется, либо, если в конструкторе будет ссылку на объект присваивать глобальной переменной, то падать у него все будет. В конце концов, либо дурь свое возьмет- и он таки сделает свое "грязное дело", либо лень свое возьмет- и он за "ЦУ" прибежит к вам. Вот тут-то вы ему мозги и вправите.

Конечно же, советов можно написать кучу- слепо следовать им все равно не получится. Основная цель- дать общее представление о том, как надо надо вести себя в команде. Приведенные выше советы- только то, что у меня "всплыло" в памяти. Хотелось бы в комментариях услышать ваши советы.
PS: Напоминаю, что я выясняю полезность сервиса редиректа URL. Если вам он интересен, то вместо e-mail просто впишите "да", если хотели бы им пользоваться, то оставьте свой e-mail для получения уведомления, когда сервис будет запущен. Адрес для голосования:
http://spreadsheets.google.com/viewform?formkey=dGxaeDlYNmdsNDBKSnprcE80Qkd4Umc6MQ
Оставленный вами адрес будет использован только один раз для уведомления Вас о запуске сервиса, после этого список с адресами будет удален. Третьим лицам адреса передаваться не будут.

Сервис маршрутизации URL

Полгода назад я перевел свой сайт на Google Sites, а блог на blogger.com. Я предупреждал о том, что переезжаю, и давал новый адрес. Но, понятно, никто не собирается напрягаться, чтобы перепроверить свои ссылки и заменить их на новые. Например, на ITBlogs, просил Михаила изменить адрес моей ленты, но даже ответа не было. Поэтому я ручками копировал RSS-ленты из blogger'a на Google Sites.
И вот, чтобы не напрягать других, и не напрягаться самому, я придумал такую штуку: беру свой исходный адрес alvosoft.com и перенаправляю его в CNAME http://www.alvosoft.com/ на Google App Engine. А на App Engine делаю простой сервис, который, получив на входе ссылку, перенаправляет ее по введенным правилам на другой адрес. В конечном итоге, я думаю, пользователю все равно, что в итоге он окажется на sites.google.com/site/alvosoft, хотя изначально он ввел http://www.alvosoft.com/. Аналогично и RSS-ленты перенаправляются по их новому адресу. Таким образом, надеюсь, что если все правильно сработает, то мне уже не придется ручками копировать ленты между сайтами.
В сервисе, что я написал, можно использовать регулярные выражения, выделять по шаблону группы и подставлять в перенаправляемый адрес. Например, все, что соответствует адресу www.alvosoft.com/itlife* (старый адрес блога) будет перенаправляться на itspeciality.blogspot.com/* (новый адрес).
Это похоже на таблицу маршрутизации по IP-адресам: исходный адрес с маской, целевой адрес. Я подумал, что такой сервис может быть полезен не только мне и готов предоставить к нему общий доступ. Если вам интересен этот сервис и вы им будете пользоваться, то скажите мне об этом:


Если интерес будет- сделаю общий доступ и уведомлю желающий о его запуске.