Дистрибутив инструментов разработки eXPressor 1.1

А чем оно от этого отличается?
Я купил - весьма доволен.
http://www.linuxshop.ru/?page=about&what=soft&item=83

> А чем оно от этого отличается? > Я купил - весьма доволен. > http://www.linuxshop.ru/?page=about&what=soft&item=83

Фраза "LinuxShop.Ru представляет вашему вниманию первый в России сборник программного обеспечения для программистов на языке Java, которые работают под Linux" не совсем корректна - eXPressor 1.0 был все-таки раньше. Впрочем, это не важно - хорошо то, что у экстремальных Java-программистов есть выбор из двух отечественных дистрибутивов средств разработки :)

Частично отличается составом и подходом к его формированию. Помимо универсальных инструментов разработки, в eXPressor включаются продукты, ориентированные именно на экстремальное программирование, например XPlanner. eXPressor спроектирован для поддержки полного цикла разработки проекта, от планирования до создания программы установки.

Помню такую фичу встречал, как экстремальное програмирование. В 2-ух словах скажите что это?

Экстремальное программирование - пагубная методология, пропагандирующая отказ от проектирования в пользу убогого суррогата (User Stories) и очень жаль, что подобная методология не умерла в зародыше, т.к. молодые программисты верят в нее и изначально идут по неверному пути.

Свое мнение об ХР я изложил здесь: http://www.vrg.ru/index.html?url=_1_4_2_1&aid=18

Сергей.

> Помню такую фичу встречал, как экстремальное програмирование. В 2-ух словах скажите что это?

См. http://www.xprogramming.ru/

> http://www.linuxshop.ru/?page=about&what=soft&item=83

Кстати, очень интересно как у них с лицензией на распространение Sun Java2 SDK. Попахивает пиратством :-)

> и изначально идут по неверному пути.
Ты забыл добавить, что это только _твое_личное_ мнение

>изначально идут по неверному пути.

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

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

В двух словах: не проектировать API (это "долго"), а сделать максимально простой код, который работает, плюс куча специальных приемов. Т.е. "быстрое и грязное" решение, ИМХО, непригодное для создание библиотек и коробочного софта. Для проектов под заказ - неплохо, т.к. позволяет ужать сроки. В большом коллективе и при сильном разбросе квалификации программистов - неприемлемо.

p.s. Это про XP. Причем, если вам нужно не мое, а авторитетное мнение, можно прочесть Effective Java Дж.Блоха...

Как вам фраза "содержат свободно распространяемые версии некоторых продуктов с закрытым исходным кодом"?!

> Как вам фраза "содержат свободно распространяемые версии некоторых продуктов с закрытым исходным кодом"?!

Хороший вопрос. Сказано так, потому что Freeware не является свободным программным обеспечением, а лишь свободно распространяемым - у пользователей нет свободы изучать и изменять код таких продуктов. Поэтому в основе дистрибутива в первую очередь свободные продукты под GPL, BSD, Apache и другими действительно свободными лицензиями.

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

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

А что не нравится? Всё правильно. Продукты свободно распространяемые, но без исходников. Хочешь пользоваться --- пользуйся, хочешь распространять --- распространяй, а исходников не дадут. Freeware. Обычное дело

Дело в том, что Free Software принято переводить как "свободно распространяемое" (см. переводы на русский в http://www.gnu.org), а FreeWare - "бесплатное ПО", которое может быть с открытыми исходниками или нет (см. там же).

>В двух словах: не проектировать API (это "долго"), а сделать максимально простой код, который работает, плюс куча специальных приемов. Т.е. "быстрое и грязное" решение, ИМХО, непригодное для создание библиотек и коробочного софта.

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

2 сторонники ХР >То что ты описываешь не имеет отношения к XP. Это как раз в >классической модели все начинается с обсуждения и планирования. Так что >это мимо тазика ;-). В XP такие вещи не обсуждаются, а сразу >кодируются, причем вместе с тестом, чтобы увидеть работоспособность >подхода. > Это как раз в стиле ХР не проанализировав и не спроектировав бросаться кодировать :)

Кстати, что сторонники ХР, называют классической моделью, методику водопада или они о RUP краем уха слышали?

Сергей

> Дело в том, что Free Software принято переводить как "свободно распространяемое" (см. переводы на русский в http://www.gnu.org), а FreeWare - "бесплатное ПО", которое может быть с открытыми исходниками или нет (см. там же).

Вы правы, существуют нюансы в переводе терминов. См. например http://www.gnu.org.ru/gnuweb/categories.html#freeware:

"У термина "freeware'' нет ясного общепринятого определения, но он часто используется для обозначения пакотов, позволяющих распространение, но не изменение (и их исходный код недоступен). Такие пакеты не являются свободным программным обеспечением, поэтому, пожалуйста, не используйте термин "freeware'', говоря о свободных программах."

Все же не стоит употреблять термин "свободно распространяемое ПО" для обозначения ПО, которое можно распространять без ограничений, обо это обещепринятый термин означающий "свободное ПО" в смысле FSF и GNU.

> Все же не стоит употреблять термин "свободно распространяемое ПО" для обозначения ПО, которое можно распространять без ограничений, обо это обещепринятый термин означающий "свободное ПО" в смысле FSF и GNU.

Ok, возможно формулировка "бесплатные версии программ с закрытым исходным кодом" действительно будет более удачной. Я согласен, что точность формулировок здесь важна, поэтому спасибо за bug report :)

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

> Это как раз в стиле ХР не проанализировав и не спроектировав бросаться кодировать :)

Ну дык, а чего тут думать? Тут прыгать надо. ;-) А если серьёзно - чем тебе не нравится такой подход - если есть test-case, который показывает работоспособность интрефейсов - зачем еще что-то проектировать?

>Кстати, что сторонники ХР, называют классической моделью, методику водопада или они о RUP краем уха слышали?

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

2maxcom: А что разве нельзя распространять SDK?

В природе нет чистых цветов.
Думаю полностью всю методологию XP никто и не использует. Но "дух XP" иногда оказывается полезным ориентиром. XP в чём-то близка к идеологии разработки OpenSource: поскольку зачастую (а в мелких проектах - всегда) нет лидера, и некому проектировать, используем самые простые, безотказные средства, если выяснится со временем чтоо что-то неудачно было сделано - перепишем. В OpenSource, как мы видим, такой подход себя оправдывает.
С другой стороны, когда в прогрраммном проекте людей много, какое-то управление всё-таки нужно, как в любом процессе, в котором много людей ;) В таком случае, "классический" подход (любой, который не-XP) оказывается более к месту. Однако, требования к участникам проекта сразу ужестотчаются, чтобы проектировать, надо рассчитывать на определённый опыт.
Так что никаких чудес, XP - это оформление идеи, давно витавшей в воздухе. Просто это внятно произнесли, книжек написали, популяризовали.

> 2maxcom: А что разве нельзя распространять SDK?

Возможно сейчас что-то изменилось, но раньше распространять SDK без дополнительного соглашения было нельзя. Runtime - можно.

Может господа из expressor'a ответят на этот вопрос по лицензированию?

> Возможно сейчас что-то изменилось, но раньше распространять SDK без дополнительного соглашения было нельзя. Runtime - можно. > Может господа из expressor'a ответят на этот вопрос по лицензированию?

Соответствующий раздел Sun Microsystems Binary Code License Agreement гласит:

C. License to Distribute Redistributables. Subject to the terms and conditions of this Agreement, including but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute those files specifically identified as redistributable in the Software "README" file ("Redistributables") provided that: (i) you distribute the Redistributables complete and unmodified (unless otherwise specified in the applicable README file), and only bundled as part of Programs, (ii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README file), (iii) you do not remove or alter any proprietary legends or notices contained in or on the Redistributables, (iv) you only distribute the Redistributables pursuant to a license agreement that protects Sun's interests consistent with the terms contained in the Agreement, (v) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.

Соответствующий раздел README:

The term "vendors" used here refers to licensees, developers, and independent software vendors (ISVs) who license and distribute the Java 2 Runtime Environment with their programs. Vendors must follow the terms of the Java 2 SDK, Standard Edition, Binary Code License agreement. Required vs. Optional Files

The files that make up the Java 2 SDK, Standard Edition, are divided into two categories: required and optional. Optional files may be excluded from redistributions of the Java 2 SDK at the vendor's discretion. The following section contains a list of the files and directories that may optionally be omitted from redistributions of the Java 2 SDK. All files not in these lists of optional files must be included in redistributions of the Java 2 SDK.

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

J2SDK не входит в состав дистрибутива eXPressor, он входит в стандартный комплект поставки на CD (в полном и немодифицированном виде) для того, чтобы пользователям дистрибутива не было необходимости загружать J2SDK с сайта Sun Microsystems. Мы надеемся, что запись J2SDK на компакт-диски с дистрибутивом eXPressor не противоречит интересам Sun Microsystems, так как способствует продвижению платформы программирования Java. Мы стремимся к сохранению всех авторских прав, поэтому если Sun Microsystems будет настаивать на исключение J2SDK из поставки дистрибутива, это будет сделано.

>Кстати, очень интересно как у них с лицензией на распространение Sun Java2 SDK. Попахивает пиратством :-)

Во-во! И я о том же! Лицензию ребята читали???

2progress:
Вы не могли бы связаться со мной - tk@linux-online.ru.
Кое какие мысли появились - может будет повод посотрудничать.

Как и у любой методики, у ХР есть своя ниша. А кроме нее есть и много других методи и методологий.
Выше говорили уже, что есть RUP. Мы вот используем MSF - там тоже на стадии анализа и планирования делаются прототипы для подтверждения проектных решений и планирования. И у нас это работает ;).

Есть интересная статья по адресу http://itc.ua/article.phtml?ID=14592
Краткий итог, который подбивает автор статьи:
----
Вот мы и пришли к последнему "Ага!". XP -- весьма привлекательная... (ну не поворачивается язык назвать это методологией) организационная идея, позволяющая неплохо работать небольшим компаниям, специализирующимся на заказном Web-программировании. Что здесь значит "неплохо", насколько оно "неплохо"... ну уж, извините, время покажет.
----