Web растет

• на десктопе перестали появляться значимые приложения (за исключением игр)
• люди проводят все больше и больше времени в интернет. Телевидение, радио и газеты сдают свои позиции

Приходит HTML5

• к концу года будет поддерживаться всеми современными (= новыми) браузерами
• открыли WebM (web media) – видео кодек vp8, его поддержали opera и mozilla.
• я не специалист, и зрение у меня не очень, поэтому не заметил особых проблем по сравнению с h264, но некоторые утверждают что качество хуже.
• Adobe встроит VP8 в Flash Player -> он появится и в устаревших браузерах -> получается единый кодек для видео в инете

Chrome Web Store

• продажа web приложений как «коробок»
• Еще один шаг к Google OS

Google Wave

• открыт для всех
• ускорен, расширен API и т.д.
• использовался для обсуждения на всех секциях Google IO, получилось очень удобно

Сотрудничество с VMWare

• Spring Roo научился генерить GWT интерфейс
• за несколько минут, на наших глазах, было написано полноценное приложение на Spring Roo для GAE + GWT

GWT 2.1

• работа на разных устройствах
• встроен MVP
• новые компоненты для отображения больших объемов данных
• Speed Tracer учитывает серверный код

App Engine

• для бизнеса
• поддержка OAuth и OpenId
• инструментарий загрузки и выгрузки данных
• планы на Comet и длительную обработку данных (mapreduce я так понимаю)

Fonts API

• набор [нестандартных] шрифтов подключаемых через CSS + Javascript

Android 2.2

• очень хорошо ускорена виртуальная машина (уже имеющиеся приложения начинают работать в 2-5 раз быстрее)
• перевод текста
• голосовые команды
• очень хорошо стебались над iPad, iPhone
• раздарили HTC Evo всем участникам конференции
• поддержка flash 10.1
• и много прочего

Google TV

• как приставка к имеющемуся телевизору, или как телевизор с встроенным Google TV
• поиск по TV каналам, с возможностью записи и т.д.
  выход в web, просмотр видео в инете, покупки фильмов онлайн (amazon, netflix, пр.)
• на него можно будет ставить приложения android
• получается интересный медиацентр для дома
• толком не работал, постоянно ломался «пульт управления»
• будет в продакшне к следующему лету

Ну и вывод: интернет меняется, и с огромной скоростью

1. Команда рано или поздно приходит к моменту когда проект «уже сделан на 90%» – что-то уже запускается (в идеалистичном use case) , есть какая-то система, казалось бы осталось лишь допилить чуть чуть.
2. Но на самом деле это лишь начало. Дальше еще столько же до того момента когда продуктом можно будет реально пользоваться, когда он станет работать у другого человека, перестанет падать в ситуации отличающейся от идеальной и т.д. Вот тут да, снова дошли до стадии «готово на 90%».
3. И это оказывается не все… Теперь нужно допилить чтобы все было «красиво», удобно, чтобы это поддерживалось, запускалось из коробки, были написаны инструкции. И после уже снова «готов на 90%», тут уже и правда почти готово.

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

Отличный пример всему этому имхо весь опенсурс, часто застрявший на первом этапе. Вот, например, популярный линуксовый десктоп: в нем огромное количество крутых штук, которых нет в коммерческих конкурентах. Это все благодаря матерым программистам. Но в тоже время в нем не сделаны банальнейшие вещи, естественные у конкурентов, и естественные для пользователя. Пример: уже 6 лет висит задачка «показывать превью картинок в диалоге выбора файлов«. Казалось бы самая естественная вещь, но висеть будет еще столько же времени, потому что матерому программисту заниматься такимим вещами не fun, это ниже его уровня, а вот процессов, менеджеров и стажеров там очень мало. И о сборе требований, анализе пользователя тоже никто пока не думает. Я не говорю что опенсурс весь такой, есть масса совсем противоположных примеров, но тут изначально условия существования проекта такие, поэтому много примеров.

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

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

А вообще вот презентация (это не то что было на официальном представлении, но суть передает):

Да, все идет к этому, к SaaS, PaaS, Enterpise 2.0, интеграции приложений под одним зонтом и пр. Мы собственно сейчас занимаемся тем же самым, посмотрим кто кого VMForce что-то реальное собирается показать во второй половине года, мы надесь тоже.

P.S. Но суть презентации я не понимаю, хоть убей, что они хотели сказать то? Все сводилось к лозунгу что «Java может работать в облаке». И чо? Кто-то разве сомневался? Не объяснили ни зачем это нужно бизнесу, ни зачем это нужно вендорам, ни что вообще хотят сделать. И вообще трансляция была полуработающая Такое ощущение что им срочно нужно было хоть что-то сказать, но времени на полноценную подготовку не было.

Так вот, мне это напомнило мою старую мысль о том что многий софт можно вообще выпускать только в виде образов виртуальных машин. Не тот который для обычных пользователей, а более серьезный. Ну вот, например, не проще ли было бы сделать «веб-мастеру» виртуальный образ среды в которой будет разрабатываться сайт, вместо Дэнвера (или что там сейчас популятно)? Вместо всех прочих хитрых SDK? Софта, который для своей работы требует поставить еще сотни мегабайт дополнительных библиотек? А корпоративный софт, особенно серверный, который поставит только сертифицированный админ, на сертифицированно настроенный сервер, со строго определенной версией ОС, на котором после этого ничего другого и не поставить? Итак ведь многие все это ставят сразу в отдельную виртуалку, так может уже и выдавать сразу готовый образ, в котором все настроено, стоит весь нужный комплект дополняющего софта и библиотек, и можно рассчитывать на то что ничего лишнего рядом не поставят? А уж сколько проблем решает виртуализация, тут тебе и многоплатформенность, и бэкапы, и миграция, и cloud computing, и пр. Ну хотя тут не мне говорить, ну хотя бы потому что не эксперт.

Или может я совсем не в теме, и вендоры ПО уже давно работают в этом направлении, и даже уже сейчас продают готовые образы?

К сожалению прям вот взять любой сайт и запустить его на GAE не получится, нужно делать именно под него, на Python или JVM, и нужно хорошо понимать как это работает. Я смотрел лишь связку Python + Django. Многие преимущества Django тут отсутствуют (например знаменитая админка django), но тем не менее результат получается очень быстро и вполне качественно. Для JVM есть многообещающий Gaelyk, ну и куча прочих framework’ов.

Плюсы

• бесплатен для небольшого проекта, и очень подходит для стартапов, с непостоянной посещаемостью. 2-3 тысячи посетителей в день обошлись в 10 центов, на совершенно не оптимизированном сайте. На нормальном должно держать тысяч 5, хотя зависит от структуры сайта, на каком-то сайте и пара сотен упрется в такой предел
• очень масштабируемо, автоматически. Мо;но не боятся слэшдот/дигг/хабра-эффектов, все выдержит.
• готовая обвязка инструментами и сервисами:
• мониторинг текущей загрузки
• версионность приложения (может работать одновременно несколько версий, можно к примеру тестировать новую версию, пока пользователи видят лишь предыдущую)
• готова вся работа с пользователем (через Google Accounts), не нужно заморачиваться с регистрацией, защитой от ботов, сменой и восстановлением пароля и пр. пользовательских данных,проверкой прав и т.д.
• cron, message queue, отправка писем, работа с графикой и web-ом

Минусы

• хостит только поддомен, т.е. домен второго уровня прицепить не получится. поэтому все сайты в виде www.* Причина в том что GAE распределенн по разным датацентрам, и автоматическую балансировку трафика они могут сделать лишь для поддомена. Не известно будут ли они решать эту проблему, это хоть и всем не нравится, но жить с этим вполне можно.
• нет поиска, что для компании, изначально на это делающей ставку, вообще странно. Мне даже в голову не могло придти что у Google не будет поиска, и ничуть не смутило то что не увидел этого в презентациях, ведь это само собой разумеющееся. Но факт: поиска нет.
• нет нормального админского инструмента для работы с БД. Есть некий GQL, но этого не достаточно, он не поможет если вам нужно быстро найти пару «плохих» записей чтобы поправить вручную. Не заработает, например, потому что скорее всего для вашей ситуации (условия выборки) не будет индекса, а без индекса запрос не выполнится. Нормально пролистать, отсортировать и пр. тоже не получится. В общем чтобы полноценно админить БД придется писать код, с нуля, так как стандартная админка Django не работает
• нет полноценной отладки, не посмотреть логи с ошибкой. К тому же SDK и боевой сервер иногда по разному себя ведут на одном и том же коде, так что это проблема. Спасает лишь то что одновременно могут быть задеплоены несколько версий, одну видят обычные пользователи, вторую вы можете самостоятельно протестировать, не показывая пока не убедитесь что все работает.

Единственный заметный результат дает «структуризация веба», а точнее структурированный и полноценный ответ на его основе. В идеале как у Вольфрама. Вольфраму более менее удалось лишь потому что они выбрали очень специфичную, узкую, и изначально структурируюмую область, в которой, к тому же, они давно сидели. Конечно же продвижения есть и остальных, и у Гугла, и у Яндекса, и особенно мне нравится как это получается у Нигмы. При этом охватить сразу всё, дать ответ на любой вопрос, им слишком трудоемко, на приборах почти не заметно, а ROI совсем плохой.

Но вот что-то мне подсказывает что есть таки еще неохваченный сегмент. А именно мобильный поиск. Только это уже не поиск, в этом случае это совсем не поиск, и даже не ответ на вопрос, а именно помощник. Мобильнику не нужен список ссылок, ему нужен конкретный ответ, сразу, в двух словах, обрезанный от всего не нужного в данном конкретном вопросе, с возможностью уточнения и взаимодействия в его контексте. Пока с этим справляется гео-поиск, это то что лежит на поверхности. Спроси у мобильного Google Maps название ресторана, и он тут же покажет где ты и где этот ресторан, покажет адрес и номер телефона, по которому тут же можно позвонить. Это вам не список ссылок о ресторане, не ссылка на офсайт ресторана, это не абстрактный ответ, а именно помощь которую ожидает пользователь.

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

А мобильный интернет тем временем ускоряется день ото дня, количество мобильных пользователей растет с огромной скоростью, и браузеры в них становятся вполне себе функциональные, спасибо майкрософту что не смог уничтожить и эту область своим Internet Explorer’ом.

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

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

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

Идея простая, и плавает на поверхности. Все равно все так или иначе это делают, кто-то пересылкой по email, кто-то Google Docs использует. А это специализированный инструмент для данной задачи.

Запускать решил сразу, сходу, как только получился прототип. Решил поэксперементировать, попробовать на практике что такое «выкатывать как можно раньше». Запостил сегодня ссылку на хабре, в результате через 20 минут топик вышел на главную, рейтинг держится на уровне +40, ~80 комментариев, пара тысяч уников на сайте, и куча советов, идей и пр. Ни смотря на такую сырость сервиса, было мало эмоциональной критики, все общение было по делу и судя по всему это очень востребованный сервис, можно доделывать. Так что показывать такую альфа-версию вовсе не страшно, и даже очень полезно. Буду иметь ввиду

Кто нибудь занимается datamining, textmining, ir и прочими делами с большими массивами данных? Вот запустил небольшой сервис: datasetpublisher.com – торрент трекер для коллекций данных. Т.е. чтобы не качать очередные 5G дампа википедии со скоростью 70Kb/s (докачается как раз к моменту когда выложат новый дамп), а скачать с нормальной скоростью через торрент.

Только запустил, поэтому там пока пусто, но будем наполнять. Если есть желание и есть что – то выкладывайте. Я, в свою очередь, постараюсь донести об этом сервисе до всех заинтересованных лиц.

Проект запущен на Google App Engine, что собственно и послужило причиной его появления. Уж очень я в последнее время заинтересовался этой платформой, и решил поэксперементировать. А так как я очень не люблю что-то делать «в корзину», и считаю что подобные эксперименты, помимо исследовательской цели, должны принести конкретный применимый сейчас результат. И вспомнил разговор с Иваном Бегтиным, незадолго до этого, о том что неплохо бы иметь подобный ресурс. Теперь он есть. И с GAE разобрался, на него еще посмотрю как вести себя будет, и напишу свое мнение.

Стахановец vs Бюрократ

Допустим один программист пишет код, просто пишет код, потому что JIRA полная задач. Ему нужно их сделать, кровь из носу.

А другой донимает его проблемами того что в ТЗ бардак, заказчик толком не понимает что хочет, код у нас не протестирован, не описан толком, в коммитах svn непонятно что, библиотеки используются не правильные, и вообще в проекте разруха, а никому до этого нет дела.

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

А если заняться улучшением процесса, то все будет внешне очень правильно, но задачи останутся не решенными, и в конце концов проект тоже провалится. Если вспомнить Кента Бека, который на Крайслере воплощал свою идею правильной разработки, методологию XP, то проект вынуждены были закрыть, не смотря на то что по нему было написано столько книг восхваляющих то как правильно его вели.

Стахановец vs Изобретатель

Программист опять пишет код, просто пишет код, потому что 3 вагона еще не закончились (на самом деле он просто не видит сколько там дальше вагонов в этом составе).

А сосед придумывает какие-то хитрые схемы развития, пусть не Канзас Шафл, но на пару лет тоже хватит. С начала утверждает что вот этот метод делающий «2 + 2» никуда не годится, его нужно разбиться распределенные сервиса (для стабильности, конечно). Проходит 1 час и новая идея: надо складывать все в очередь на вычисление, периодически поднимать кластер на Amazon EC2, и там Hadoop’ом считать сумму. Потом еще подумает и скажет что Hadoop это фигня, надо на Erlang, потому что mapreduce это прошлый век, и что тут есть огромный потенциал к тому чтобы еще лучше распараллелить, но нужны особые возможности.

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

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

Бюрократ vs Изобретатель

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

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

Конфликт

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

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

Он выделил 4 роли: Producer – Administrator – Enterpreneur – Integrator – сокращенно PAEI. Адизес описал все в общем случае, мне же это интересно на примере команды разработки ПО. Только я позволю себе перевести названия ролей не дословно.

Стахановец – Producer

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

Ему важно что он делает, и как. С презрением смотрит на все что не помогает в его работе. Ну например багтрекер, отчеты о проделанной работе, письма и тем более все эти совещания. Зачем они ему? Он и так знает что он делает, что сделал и что дальше ему делать. И каждая минуты потраченная на эти, казалось бы, бесполезные вещи отнимает время от выполнения своей основной работы, что он очень не любит.

Бюрократ – Administrator

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

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

Изобретатель – Interpreneur

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

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

Политик – Integrator

Ему важно чтобы все были согласны с задачей, и пока все не скажут что они обсудили и нужно сделать именно так как они говорят. Он не нажмет и клавиши, даже если в багтерекере задача стоит с максимальным приоритетом. Ему важно чтобы задача была действительно важная, нужная всем, что бы все договорились и пришли к единому мнению. И пока он этого не увидит, он будет со всем соглашаться, поддакивать, но ничего не делать, пока будет сомневаться в том что все уже решено. Лишь потому что он не готов делать что-то, что может кому-то не понравиться.

Конфликт ролей

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

Рекомендую прочитать одну из книг этого автора, например Идеальный руководитель: Почему им нельзя стать и что из этого следует или почитать в инете, если интересны подробности, и, например, то как согласовать эти роли и добиться конструктивного конфликта. Я, в свою очередь, постараюсь тоже написать об этом, чуть позже.