Самая последняя компания, которая сделала это — это VMWare. Продукт этой компании столь стремился к изменениям, что породил новое движение в плане визуализации операционной системы, что превратилось в огромный рынок.
Переводчик уверен, что в оригинале было написано именно ЭТО?
"SOA is not just about the message-passing architecture, which is why Microsoft SOA is significantly different from IBM," he added. "The (Microsoft Developer Network) mechanism is a lightweight messaging infrastructure in a message-based environment, whereas IBM delivers a fully functioning infrastructure."
IBM прочно сидит в сфере интеграции больших, тяжелых приложений еще начиная с мрачного средневековья (MQ). И конкурировать с ней в этой области Microsoft не в состоянии. Соответственно, их единственный шанс окучить мелкий бизнес. Для которого, с одной стороны, нехарактерны гетерогенные среды и, с другой стороны, актуальна экономия ресурсов. Соответственно использование облегченных (как в рантайме, так и применительно к сложности разработки) протоколов.
Так что OOXML в исходном материале в значительной степени притянут за уши...
В ряде фирм для этого создается отдел, целью которого является настройка процессов внутри компании.
При формально прописанном процессе знания действительно накапливаются при условии, что эта группа заставляет всерьез относиться к составлению послепроектных отчетов и постоянно использует эти отчеты при подстройке процессов.
Поскольку лично с меня никто документ не требует я его не составляю. Но в органайзерах у меня по каждому проекта последних 6 (сейчас проверил) лет есть "финишные" записи: что лично я сделал хорошо/плохо, на что обратить внимание в следующем проекте. Примерно по 20 органайзерных страничек на проект.
Поскольку составляется для внутреннего использования, можно позволить себе более жесткий анализ. :)
Не очень понятно, что автор опроса понимает под словом "сайт". Корпоративный портал и сайт в две странички для бюро ритуальных услуг нет смысла делать, используя один универсальный процесс. Я уж не говорю о том, что список предлагаемых вариантов... как бы это помягче... очень странно подобран.
Да, можно формально сказать, что вначале по ТЗ уточняются требования и затем рисуется информационная архитектура и формулируются требования к юзабилити. Но для сайта бюро ритуальных услуг весь этот процесс занимает 30 секунд и сводится к единственному уточняющему вопросу: "цены на гробы вынести в отдельную страницу?"
Я вижу, сейчас в голосовании лидирует доскональное продумывание на бумаге. Честно говоря, это не соответствует тому, что я наблюдаю в реальной жизни. Хотя бы потому, что есть очень обширный пласт заказчиков, которые в состоянии внятно отвечать на уточняющие вопросы только увидев дизайн.
- Нам кажется, что для вашего сайте нецелесообразно вынесение в главное меню пункта "Вакансии"...
- Ну вы пока дизайн нарисуйте как есть, мы потом посмотрим и подумаем.
Кроме того, очень невелик процент веб-разработчиков, которые умеют "досконально продумывать на бумаге". Бумага предполагает, что результат сможет прочесть кто-то другой, не только автор. Иначе и сам через неделю не прочитаешь правильно. Это означает использование общепринятых схем. Тот же UML, гарретовский Visual Vocabulary или что-нибудь еще. И что, в реальной жизни сорок с гаком процентов веб-разработчиков профессионально использует это? Очень сомнительно.
Еще раз: ограничения перестали устраивать. На момент сдачи все было в порядке. :) Но во время поддержки у заказчика, разумеется, изменились требования.
Если устраивают да. Но я хорошо помню, как быстро меня перестала устраивать ограниченная версия MSSQL 6.5 на реальном проекте, который изначально в нее вписывался.
Я бы сказал, что СУБД выбирают как компромис между стоимостью приобретения, стоимостью владения, требованиям к функциональности и нагрузочной способности.
Если у меня бюджет проекта $5000 на разработку и $1000 на поддержку в месяц, то я никак не смогу выбрать Oracle.
Все люди без каких-либо ограничений могут писать в этом блоге.
Для чего это нужно?
Во-первых, новички могут представиться миру, прямо в этом блоге, чтобы их заметили, но для этого нужно представиться как следует. Во-вторых, людям с отрицательно кармой тоже хочется писать. Может быть для того, чтобы карма стала положительной.
Когда человек кидает в этот блог пост, в котором выражает СВОЕ интересное мнение народ с большой вероятностью плюсует и топик, и карму автора.
Когда человек кидает в этот блог нечто, никак не выражающее его личное отношение ссылку на новость с известного ресурса, опрос без какого-либо внятного предваряющего текста и т.п. вполне логично, что это вызывает отрицательную реакцию.
Искусственный интеллект нужен там, где не получается применить дешовый естественный. Простейшие примеры:
1. Противокорабельная ракета, которой нужно обмануть оборонительные системы корабля. Индусов, конечно, нанять можно. Но они, во-первых, не успеют. Не то время реакции. Во-вторых, нужное количество не помещается в ракету. Да и перегрузки, характерные для маневрирующей ракеты, они переносят плохо.
2. Экспертная система, ставящая предварительный диагноз по результатам анализа мочи пациента. Посадить 1000 индийских докторов и устраивать голосование?
У меня такое ощущение, что автором заметки мысль Баха понята с точностью до наоборот. Берем цитату:
К примеру, можно научить графический редактор обрезать края у изображения (при подготовке к печати), но нельзя разъяснить ему, в каких случаях нужно отрезать с одной стороны больше, а с другой меньше. Поэтому этот процесс разумным назвать нельзя.
По Баху строго наоборот. Он классифицирует процесс как sapient, если он НЕ может быть полностью автоматизирован и из него НЕ МОЖЕТ быть полностью исключен человек. Это хорошо видно из примера, который приводит сам Бах:
Is digging a hole a sapient process? It might be. Consider an archeological dig. There’s no simple algorithm or tool that will automatically excavate a valuable historical site while we go and watch TV.
Получается довольно странно: перевод материала изз заметки Баха точен, а собственный пример про обрезку совсем не в тему...
Переводчик уверен, что в оригинале было написано именно ЭТО?
IBM прочно сидит в сфере интеграции больших, тяжелых приложений еще начиная с мрачного средневековья (MQ). И конкурировать с ней в этой области Microsoft не в состоянии. Соответственно, их единственный шанс окучить мелкий бизнес. Для которого, с одной стороны, нехарактерны гетерогенные среды и, с другой стороны, актуальна экономия ресурсов. Соответственно использование облегченных (как в рантайме, так и применительно к сложности разработки) протоколов.
Так что OOXML в исходном материале в значительной степени притянут за уши...
Это язык для детей с необратимыми отставаниями в развитии?
При формально прописанном процессе знания действительно накапливаются при условии, что эта группа заставляет всерьез относиться к составлению послепроектных отчетов и постоянно использует эти отчеты при подстройке процессов.
Поскольку составляется для внутреннего использования, можно позволить себе более жесткий анализ. :)
Текущий регулярный анализ в ходе проекта абсолютно необходимая вещь. Иначе процесс просто выходит из под контроля.
Суммарный анализ после завершения единственный способ не повторить совершенные ошибки в будущем.
Да, можно формально сказать, что вначале по ТЗ уточняются требования и затем рисуется информационная архитектура и формулируются требования к юзабилити. Но для сайта бюро ритуальных услуг весь этот процесс занимает 30 секунд и сводится к единственному уточняющему вопросу: "цены на гробы вынести в отдельную страницу?"
Я вижу, сейчас в голосовании лидирует доскональное продумывание на бумаге. Честно говоря, это не соответствует тому, что я наблюдаю в реальной жизни. Хотя бы потому, что есть очень обширный пласт заказчиков, которые в состоянии внятно отвечать на уточняющие вопросы только увидев дизайн.
Кроме того, очень невелик процент веб-разработчиков, которые умеют "досконально продумывать на бумаге". Бумага предполагает, что результат сможет прочесть кто-то другой, не только автор. Иначе и сам через неделю не прочитаешь правильно. Это означает использование общепринятых схем. Тот же UML, гарретовский Visual Vocabulary или что-нибудь еще. И что, в реальной жизни сорок с гаком процентов веб-разработчиков профессионально использует это? Очень сомнительно.
Если у меня бюджет проекта $5000 на разработку и $1000 на поддержку в месяц, то я никак не смогу выбрать Oracle.
Но практика показывает, что достаточно много людей способны на большее, чем копипэстить общедоступную информацию.
Когда человек кидает в этот блог пост, в котором выражает СВОЕ интересное мнение народ с большой вероятностью плюсует и топик, и карму автора.
Когда человек кидает в этот блог нечто, никак не выражающее его личное отношение ссылку на новость с известного ресурса, опрос без какого-либо внятного предваряющего текста и т.п. вполне логично, что это вызывает отрицательную реакцию.
1. Противокорабельная ракета, которой нужно обмануть оборонительные системы корабля. Индусов, конечно, нанять можно. Но они, во-первых, не успеют. Не то время реакции. Во-вторых, нужное количество не помещается в ракету. Да и перегрузки, характерные для маневрирующей ракеты, они переносят плохо.
2. Экспертная система, ставящая предварительный диагноз по результатам анализа мочи пациента. Посадить 1000 индийских докторов и устраивать голосование?
По Баху строго наоборот. Он классифицирует процесс как sapient, если он НЕ может быть полностью автоматизирован и из него НЕ МОЖЕТ быть полностью исключен человек. Это хорошо видно из примера, который приводит сам Бах:
Получается довольно странно: перевод материала изз заметки Баха точен, а собственный пример про обрезку совсем не в тему...