(no subject)

[singalen]

Прочитал про "младшего брата" слова RTFM, STFW. Забавно. Кстати, чудесный текст.
Мне сказали, что корпоративные информсистемы на .NET пока что не особо успешны, и это из-за отсутствия хорошего аппсервера. Интересно, почему так? И зачем обязательно сервер приложений?
Не боясь показать чайниковую сущность, спрошу: почему вообще важен аппсервер? Скажем так: это же фреймворк. Если не делать inversion of control, а добиться тех же функций от библиотеки, скажем, персистенции от Hibernate-а-не-EJB, IPC от CORBA-а-не-SOAP, и так далее - то серверный процесс будет сам себе application server, вернее, сервером бизнес логики.
Пошёл учиться, учиться и учиться, как завещал Ленин. И делать STFW.

Comments

[singalen]

Хоба! Поделитесь знаниями :)
Какие книги читать, какие паттерны приняты в архитектуре, за чем следить?
А для чего именно не хватает аппсервера?

[johndegree.livejournal.com]

на самом деле, по моему глубокому убеждению после изучения 3..4 разноплановых языков/платформ/парадигм уже все равно на чем девелопить. Естественно вопрос удобства девелопмента и наличия инфрвструктур остается актуальным, но это первые 6..8 месяцев активного девелопмента. Для справки - я говорю о системах для которых объем девелопмента от 10 человеко ДО БЭТЫ.
Паттерны и книги классика - Фаулер, Гамма, ну и все что написано достаточно абстрактно чтобы не привязывать мозг к конкретной платформе. Меня после определенного периода хорошо пнули вперед книги по системному анализу и различным видам декомпозиции. Потом книги которые я считаю Holy Bible "постдевелоперского" образования - unified process.
Относительно инфосистемы для госпиталей которую мы девелопим - попервой заказчики стремались и постоянно пытались подвинуть разработку на более традиционные платформы. Окончательно все сомнения по поводу .net уляглись после того как на одной выставке CEO мед подразделения одной огромной конторы (типа сименс-филипс-ДжиИ :) спросил где наши заказчики купили контору с таким продуктом. Ему попытались объяснить что группа менее чем из 10 разработчиков сделала это менее чем за 2 года он не поверил :)
Сейчас нас попросили сделать mission critical систему для госпиталей которая в будущем сможет работать в отделениях интенсивной терапии, и неожидпнно попросили сделать это на .Net :) Вот хдесь и не хватает апп сервера, нам нужен некоторый модуль который будет предоставлять доступ к бизнесобъектам системы и будет иметь возможность независимо перезагружать свои подсистемы(applications), сможет объеденяться в кластера ну и все остальное что предоставляют свякие веблоджики :)
Отакэ от :)

[nponeccop.livejournal.com]

Но "будет иметь возможность независимо перезагружать свои подсистемы(applications), сможет объеденяться в кластера" - это же что-то типа прокси для load balancing и high availability. Это все, что возлагается на application server?

[johndegree.livejournal.com]

>Это все, что возлагается на application server?
и все остальное что предоставляют вcякие веблоджики. там много всего типа persistence, messaging etc.

[nponeccop.livejournal.com]

Но речь то шла о другом - почему это нельзя переложить на библиотеку?

[johndegree.livejournal.com]

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

[singalen]

А что есть в этой функции фиговины, кроме persistence service и, может, load balancing-а?

[voidbent.livejournal.com]

> после изучения 3..4 разноплановых языков/платформ/парадигм
> уже все равно на чем девелопить.

А можно про раpноплановые парадигмы по подробнее? :)
Имеется в виду процедурное\объектно-ориентированное програмирование или что-то другое?

Для меня, просто, даже только выбирая между этими 2-мя парадигмами-братьями (далеко не разноплановыми) не всё равно на чём девелопить. Не говоря уже про что-то там логическое ...

[johndegree.livejournal.com]

>А можно про раpноплановые парадигмы по подробнее? :)
есть еще аспектно ориентированное, кучу всякой экзотики на cetus-links можно посмотреть и в конце концов парадигма языка программирования "черепашки" :))) кстати вот ассемблер для процессора с кучей конвейеров и предсказанием ветвлений это к какой парадигме? ;)

>Имеется в виду процедурное\объектно-ориентированное програмирование или что-то другое?
угу, оно самое.

>Для меня, просто, даже только выбирая между этими 2-мя парадигмами-братьями (далеко не разноплановыми) не всё равно на чём девелопить.
само собой, одна задача решается легче так, другая эдак, чем больше продукт тем сложнее выбор.

[voidbent.livejournal.com]

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

(Кстати есть такая книжка, называеться Одинцов И. Профессиональное программирование. Системный подход., там приводиться классификация методологий Тузова В. А. и по этой классификации методологий всего 9 )

Я просто хочу немного покритиковать глубокое убеждение по которому "после изучения 3..4 разноплановых языков/платформ/парадигм уже все равно на чем девелопить." :)

Если-бы меня сейчас посадили девелопить на AspectJ-е или FutureC++-е то я бы не очень этому обрадовался. Да и сомневаюсь что это было-бы оправданно с точки зрения бизнеса например.
Поэтому мне не всё равно на чём девелопить :)

[singalen]

AspectJ - не самостоятельный язык, это "примочка".
Что такое FutureC++ - найти не смог.
А ещё мне кажется, что в этой ветке ты обсуждаешь вопрос вкуса.

[nponeccop.livejournal.com]

Различия между языками постепенно стираются когда узнаешь их лучше. Соответственно и вкусы становятся более широкими.

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

[voidbent.livejournal.com]

FutureC++ - это написанное c ошибкой FeatureC++

> А ещё мне кажется, что в этой ветке ты обсуждаешь вопрос вкуса.

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

[nponeccop.livejournal.com]

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

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

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

А так - выбор между скажем ASP (на любом асп-языке), PHP, Perl для реализации веб-проекта - почти не принципиален. Я не сильно огорчусь узнав о любом решении руководства.

То же можно сказать о Delphi, VB6, C, C++, XUL и HTA для десктоп-приложений.

Ну и так далее...

[nponeccop.livejournal.com]

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

[voidbent.livejournal.com]

А я и не говорил что классная :) Я просто сказал что там это есть :)
А можно ссылку на Пратта-Зелковица если есть под рукою?

[johndegree.livejournal.com]

за адекватное вознаграждение я какое то время назад разбирался с RPG под AIX после этого я прекрасно знаю что "сумашедшим деньги не нужны", но жить можно даже там :)
а про покритиковать так это дело нужное, хотя я жыж написал про "МОЕ глубокое убеждение" :)

[voidbent.livejournal.com]

> хотя я жыж написал про "МОЕ глубокое убеждение" :)

Вот я именно его покритиковать и хотел ;)

[johndegree.livejournal.com]

>...по этой классификации методологий всего...
я не говорил слово "методология"!!! Я не хочу another holy war XP vs. RUP :)))

[nponeccop.livejournal.com]

Через некоторое время становится всё равно. Процедурное и объектное программирование отличаются только на первый взгляд. На самом деле если вы будете передавать в C указатель this явным образом, будете эмулировать наследование агрерацией, а виртуальные методы - указателями на функции, то сможете любой "объектно-ориентированный" код на C++ перевести в "процедурный".

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

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

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

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

[voidbent.livejournal.com]

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

[nponeccop.livejournal.com]

Что вы подразумеваете под "сквозной функциональностью"? Давайте к ней прицепимся ради примера.

На этапе бизнес-модели я могу какие угодно квадратики и облачка рисовать. Могу смешать в одну кучу entities, processes, states, activities... Она будет практически одна независимо от того как я потом это по файликам с исходным текстом разложу. То есть иетодология имеет какое-то влияние на этапе дизайна, а на этапе анализа никакого программирования нет, не то что методологии.

[voidbent.livejournal.com]

> На самом деле если вы будете передавать в C указатель
> this явным образом, будете эмулировать наследование агрерацией ...
> Но это на нижнем уровне.

Угу. Знаем. А ещё уровнем ниже машина Тьюринга на которой можно сэмулировать ява машину и которою можно сэмулировать на ява машине.

Но я всё-таки предпочёл бы програмировать ява машину а не машину Тьюринга :)

[nponeccop.livejournal.com]

Вы посмотрите на код Апача. Он написан на Си с применением объектно-ориентированной методологии.

Загляните ко мне в ЖЖ и найдите там пример функционального программирования на Перле.

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

[nponeccop.livejournal.com]

Вот! "вопрос удобства девелопмента и наличия инфрвструктур". Откуда вы взяли про парадигмы? Из первого предложения?