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

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

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

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

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

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

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

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

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

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

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

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

В сети находите 3 варианта покупки:

• 10 тыс. руб – и как получится, может завтра, а может через месяц, может вообще не доставят, но денег в любом случае не вернут. К тому же на корпусе могут быть какие-то подозрительные царапины и непонятные люди в списке контактов. Или вообще другой телефон привезут, ну и может денег сверху попросят, лишь потому что у них там какие-то непонятные вам «проблемы возникли с товаром«.
• 15 тыс. руб – может быть завтра уже доставят, но черт его знает на самом деле, есть некоторая путаница со складами, курьерами, наличием, в общем они обещают на днях позвонить и сказать точнее что как будет, может сразу доставят, может в течении недели, ну или как получится.
• 20 тыс. руб – послезавтра ровно в 14:25 курьер с товаром будет у вас в офисе. точка.

Вы какой выберете? От чего зависит решение?
Если по цене, то третий вариант в 2 раза дороже первого. С другой стороны у него гарантия доставки, или вы готовы сидеть на одном месте и ждать курьера сколько угодно?
А если вы руководитель компании и закупаете их сотрудникам, что вы им скажете? А перед своим руководителем в такой ситуации как обоснуете выбор и отчитаетесь?

На самом деле почти риторические вопросы, просто повод поразмышлять о том как думает заказчик разработки софта. Цена, предсказуемость результата и пр.

PS: а еще можно было бы это разбить на 5 вариантов, чтобы сопоставить с уровнями CMMI

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

На каждую хитрую задачу найдется свой jar с винтом.

ну может не всегда именно jar, а скорее технология, протокол, спецификация, но суть в общем такая.

У всех остальных все хуже. Там или узкая заточенность под одни нужды (RoR), или единая линия партии (.Net), или просто полный хаос.

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

Поэтому нравится java или нет, но… но чаще всего выбирать и не из чего.

P.S.: Хотя, если честно, есть тут один минус: это то что привыкнув к этому все стараются делать «через жаву», что не всегда верно, но это уже издержки производства.

А мне всегда как то хватало связки Spring + Hibernate + Tomcat/JBoss, что в сущности дает тоже самое, но удобнее. Список можно продолжить добавив еще как минимум Acegi, AspectJ, и прочие решения умеющие хорошо и удобно решать свою отдельную задачу, многие легко взаимозаменяемы и дают очень неплохой синергетический эффект.

EJB немного был когда я работал в Luxoft, но это почти мимо меня прошло. К EJB как таковому у меня отношение отрицательное из-за больших объемов лишней работы, я считаю что простые вещи должны делаться просто. Для EJB это не выполнялось, простые вещи делались сложно. Да и, честно говоря, сложные вещи делались не сложно, а очень сложно. Тоже самое касается и JSF. Система становится всеобъемлющей, делает все что можно, но, как результат комплексности, делает «все» одинаково плохо. Говорят с EJB 3.0 все лучше стало, т.к. изучили опыт аналогов (читай стараются догнать). Но это немного поздно, и с учетом инертности крупных разработчиков все совсем плохо.

Все это рассчитывалось на то что с этим сможет работать совершенно некомпетентный специалист, который возьмет какую либо GUI рисовалку и, не понимая базовых принципов, наклепает работающее приложение. В результате совершенно непонятно как вся эта хренотень может работать, и требует огромных компьютерных ресурсов. Хотя для последнего всегда проще купить HP Superdome и не парится (к тому же часто наоборот, сервера уже стоят, а загружены на 10%, но это уже решается другими методами). На самом деле я даже согласен, часто действительно лучше и гораздо дешевле поставить железо мощнее, но только когда это не вызвано уродством архитектуры. Т.е. когда мы пишем сервер на Ruby (например) и получаем красивое технологически решение, поддерживаемое и легко расширяемое, то потребность в больших ресурсах вполне себе оправдана, но когда говорят «а нафиг нам пул соединений с БД? без него точно все работает, а с ним вдруг что случится? у нас сервер хороший и без пула потянет!» то тут уже не сервер ставить, а архитектора увольнять. Хотя и мысль теоретически даже правильная, но не в том месте.

JSF больше страдает клиентской избыточностью, но для intranet на это еще можно забить. Я даже пару раз пытался использовать это, но так и не понял вкуса. К тому же если нужно создавать хороший интерфейс не заморачиваясь с html/javascript, то надо использовать GWT, а не JSF. Но это, конечно, если нет в требованиях пункта «поддержка Netscape Navigator 3.0″, что еще было обязательным года 3 назад, надеюсь сейчас эти «компьютеры» уже окончательно доломались и на замену поставили те где можно поставить браузер посовременней.

А то к чему приводит разработка лишь на JSF могу проиллюстрировать тем что на очередном собеседовании с большим недоверием отнеслись к тому что я могу редактировать JSP/HTML в текстовом редакторе, вместо положенного WYSIWYG редактора. Очень удивились тому что я могу предполагать как изменится внешний вид в браузере после редактирования исходного HTML этой страницы. Я по своей наивности считал это вполне обыденной вещью, которую можно поручать даже школьнику-верстальщику. Ладно хоть не сказал что, к примеру, еще понимаю как HTTP протокол организован и на сайты хоть телнетом ходить могу.

Та вот, к чему я. В начале заголовок статьи был «Я не использую EJB и JSF», сейчас заменил на «Я не знаю EJB и JSF». Т.е. это скорее не принципиальное решение, а ситуация. Ведь может быть действительно моя проблема в том что я не знаю их? Может там есть очень серьезные плюсы? Серьезные выигрыши для проекта, для архитектуры, по сравнению с теми же Spring, Hibernate и пр.? Снижение каких то рисков? Если в случае EJB еще более-менее понятно, само по себе оно нужно, как минимум все части по отдельности востребованы. Вопрос в том нужны ли столь тяжеловесные решения иногда для простых задач, когда есть прекрасные и удобные альтернативы. Иногда конечно стоит взять готовую коробку от IBM, Oracle или BEA, вместо набора различных OS кубиков типа Mule, ActiveMQ, JBoss, Hibernate, Spring и т.д. Это касается EJB, а вот в случае JSF мне вообще непонятно как оно до сих пор существует и кому это надо, неужели JSF дает что-то такое что разработка становится настолько дешевле?

sdx:"bfpvcgjkqsxzdtlmnr"!(4#1),(8#2),(3 3 4 5 5 6)
nn:{d2:x where x > 0;r:d2 where d1:0w<>':d2}
soundex:{(x[0],(nn (sdx@1 _ x)),l:4#0)[til 4]}

угу, именно так… Похоже что клавиатуру протирали.
Теперь запускаем:

>soundex "hellomyfriends"
("h";4;5;1)

А оно работает даже!

На самом деле из меня пока еще никакой специалист по K, и в действительности саму функцию (т.е. последние 2 строки) наверняка можно переписать укоротив раза в 2-3, вообще для такой мелочи должно 1 строки кода хватать, так что мой пример нифига не лаконичен. Но идея думаю понятна. На Java тоже самое было бы гораздо длиннее, я приводить алгоритм soundex не буду, но можете посмотреть на другие сравнения синтаксиса Java и K

Честно говоря вся фишка языка K вовсе не в том что он такой компактный, а в Kdb+ и их совместных возможностях, но все же, я именно о синтаксисе. Для Java кода, при кодревью, я всегда помечал записи вида:

x += isEmpty(s) || isDigit(s) ? 1 : 2;

и требовал что то вроде:

if (isEmpty(s) || isDigit(s)) {
    x++;
} else {
    x += 2;
}

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

Так вот для человека, который не знает программирования, а тем более уж Java и K, оба языка покажутся «китайской грамотой», и лишь для специалиста будет понятно, причем лишь тот пример на языке которого у него есть реальный опыт.

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

С другой стороны когда реализуешь алгоритм немного раздражает что пишешь сотни строк не относящихся напрямую к алгоритму (конечно постоянные Ctrl+Enter немного облегчают, но все же это не панацея), а после не можешь его окинуть взглядом и чтобы понять как оно работает появляются уродцы типа UML диаграмм. Ну и вообще пока описываешь эти бесконечные иерархии начинаешь забывать что собственно пишешь. Кстати, а может устроить программирование как в шахматных партиях: 8 машинисток и идти вдоль ряда, лишь парой фраз указывая каждой что ей нужно писать? В случае Kdb+/K ходит история что некоторые, совсем уж хакеры, на ходу, собственно в процессе получения ТЗ от зрителей, за 1-1,5 часа пишут небольшую ERP.

Так вот, к чему я, если отвлечься от «java разработчика без проблем найти, а под K замучаешься», то возникает вопрос: а все же как лучше? С одной стороны простота, с другой скорость реализации. Весь этот синтаксический overhead уже заставляет java разработчиков искать себя в ruby, python, groovy. Этакая золотая середина?

• замена в определённом поле
• удаление по определённому регекспу
• сортировка
• удаление пробелов

Получаем вот такой вот файлик:

--- !replace
from: __UNKNOWN__
to: Computer
atField: author
--- !remove
regex: [^\\d]+
atFields:
  - year
  - phone
--- !sort
withComparator: !defaultComparator
  direction: desc
--- !transform
withTransformer: !trim{}

Этакий Domain Specific Language получается. Может на первый взгляд не так все просто, но если написать небольшое описание синтаксиса нашего языка, или знакомство с документацией по yaml, все встанет на свои места, и редактирование подобного списка команд становится несложной задачей, с которой может справится продвинутый пользователь. В общем я сейчас сильно в синтаксис не буду вдаваться, кому надо глянут на yaml.org и jyaml.sourceforge.net
Второй момент как это прочитать, т.е. как построить их этого файла наши объекты. Делается все просто, через упомянутый JYaml:

List<Command> list = new ArrayList<Command>();
YamlDecoder dec = new YamlDecoder(in);
try {
    while (true) {
        Command command = (Command) dec.readObject();
        list.add(command);
    }
} catch (EOFException e) {
    log.debug("Finished reading stream.");
} finally {
    dec.close();
}

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

BiDirectionalMap<String, String> classes = new BiDirectionalMap<String, String>();
classes.put("replace", ReplaceCmd.class.getName());
classes.put("remove", RemoveCmd.class.getName());
classes.put("trim", Trim.class.getName());
classes.put("sort", SortCmd.class.getName());
classes.put("defaultComparator", DefaultComparatorCmd.class.getName());
classes.put("transform", TransformCmd.class.getName());
YamlConfig.getDefaultConfig().setTransfers(classes);

На самом деле можно такой мини язык делать не только для списка команд, в общем то почти любой класс так можно описать и десериализовать после в объект, а текущая задача она применима к моим условиям. Правда тут возникла проблема: хотелось бы чтобы эти объекты помимо описания в этом файле имели настройки в Spring. Т.е. все связи с другими объектами настроить в Spring контексте, а саму очерёдность и дополнительные настройки брать уже из этого файла. Так вот это я не знаю как реализовать, не расширяя YamlDecoder. Хотя, т.к. jyaml проект open source’ный, это тоже вполне реализуемо.

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

Так вот такое же насыщение сейчас пришло в Web. Сейчас пошли все эти новые технологиий RSS, RDF, SOAP, Semantic Web и пр. Т.е. переход от «сайт как единое целое» к «сайт как участник связанной системы». Сайт начинает связывать/использовать для своей работы некоторые другие сайты/сервисы, а также сам может отдавать другим какие либо свои услуги/информацию. Остается только договорится о стандартизации обмена, об API доступа к сайту. Это уже не сайты, а сервисы.

И вполне вероятным может быть создание сайта лишь на основе иных сервисов. Это несомненно дает множество плюсов, в плане качества сайта. К примеру я могу прикрутить к определенному сайту карту местности, если делать буду ее своими силами. Но сколько денег это мне будет стоить? Есть у меня один знакомый, который занимался много времени ГИС-софтом, он мне примерно рассказал сколько ресурсов это потребует, в общем дорого это… Но есть путь проще: к сайту прекрасно прикручивается Google Maps. Еще из подобных сервисов у нас уже есть различные чаты, календари (GCal), хранилище данных (Amazon S3), фиды по кучи разных тем… еще много чего, но на самом деле еще мало

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

Вот это уже и есть Web 2.0. А все эти закругленные углы, большие шрифты, css, ajax, и пр. это просто обычный процесс улучшения, просто попавший на этоже время.