В общем задача: написать web-приложение на j2ee.
web-приложение (довольно сложное) должно будет использовать ajax (одно из применений: карта маршрутизации: всякие стрелочки, лампочки – что происходит; логирование)
Нужна какая-либо библиотека для java которая:
1) позволяла бы написать такое ajax приложение
2) нормально встраивалась в Spring
Еще: все будет крутиться под WAS'ом (имхо, может он что то позволяет такое делать???) и чтобы удобно было юзать (исправлять) JS который будет генерить библиотека.
Меня интересует что можно использовать, и отзывы если кто-нить юзал GWT (Google Web Toolkit((//code.google.com/webtoolkit/ ))?
*GWT не только по отношению к java, вообще как фреймфорк
20 октября 2007 в 18:03
а всяческие темы типа ajax4jsf использовать нет желания?
на последних richfaces работать с аякс довольно прозрачно получается. На лету править js код возможности нет, но есть хорошие возможности по интеграции своих скриптов и того что генерит фильтр.
13 сентября 2007 в 22:02
Нет исходников — юзай дизассемблер.
13 сентября 2007 в 21:05
ну если кофе булочки и генту……вот ума-разума наберусь))) а то сложно с коллегами-гениями не гениям общаться))))
С днем программиста!))))
"Мы бы изменили мир, но Бог не даст нам исходник"
12 сентября 2007 в 22:03
Полной свободы, конечно, не получишь: например, балансирующий веб-сервер может держать 50 000 коннектов только, если он написан на Си, следовательно, тебе нужен Си, если хочешь написать для него модуль. Но это ограничения, связанные с задачей, а не фантазией менеджера. (Кстати, никто не мешает тебе поставить YAWS на Эрланге, если хочется: онтоже супербыстрый, но к нему экстеншены лепить тяжело, и они отваливаются, — тоже минусы).
"PPPS хотя я никогда не могла понять – почему нельзя ВСЕ и СРАЗУ???"
У нас есть всё и сразу
Удобная клава, стул, чай-кофе-булочки, мощные серверы, свободные технологии, интересные задачи, время, коллеги-гении, ос, которую хочешь (у меня – мак, у остальных – линуксы и винды).
12 сентября 2007 в 20:04
)) в общем фантазия у мня богатая))))
12 сентября 2007 в 20:03
) что то наподобие: в поисках счастья????
я до текущего места работы, я тоже работала в 3-х конторах:
1) компания С.: род деятельности – внутренняя автоматизация, средство – LAMP (+Перл, Питон). Свобода действий – безграничная (главное чтоб работало и в срок). Вроде все круто, но(!) были тонны ненужного кода, по N раз переписывался собственный фраймворк….. (на самом деле прикольно: попытка найти что-то светлое), но задач интересный и нужных было крайне мало…а сложных и того меньше…..а потом оказалось – что это никому не надо. В общем компания закрылась сама и => наш отдел. 5 программистов+архитектор/ведущий.
2) Пришла в компанию Б сцелью: посмотреть как работает компания, которая продает свои услуги…..это была известная web-студия в нашем городе. Работа – конвеер, называется……Минус? времени на творчество (в отличии от 1) ) просто нет: кто-то подправляет внутренний софт, кто-то тут же разрабатывает новый, а третьи осуществляют поддержку…..вопроса о выборе технологий средств и тд просто нет: некогда….надо быстрее быстрее делать и сдавать……
3) где работаю в данный момент: очень серьезная компания (у нас в городе такого уровня – одна….ну или почти одна), много серьезных людей: аналитиков, программистов и тд. Понятно, что много бюрократии. Работа с некоторыми заказчиками ведется много много лет.Много очень умных и талантливых архитекторов, программистов, аналитиков (с другими не контактирую). И задачи…..таких задач больше *почти* нигде нет (в плане они не тривиальные и сильно специфические). Опять же но: про то, что говорили – из-за этого сложно интегрировать и использовать "новые" технологии при разработке:: много много задействовано……ибо не от нас зависит…..Вот только задачи – как программисту интересны и мысль (как реклама у яндекса была) "это делаем только мы и только у нас". Парадокс – но в 3) зарплатанизкая (относительно тех. же вакансий у нас в городе), а знать надо много. Но тут мне нравиться задачи. И вообще (в сравнении)…но я уже говорила
Заметил? в 3) много всего…..
А в 1) и 2) нехватало……
Честно: не верю, чтобы была свобода (в плане выбора технологий, разработки и тд), и были интересные задачи. Было время. Нервы. Коллеги. И кофе с булочками. Компьютер. Стол. Удобная Клава. Та OS которую хочешь ты. Карандаши.
Задачи…..задачи….задачи…..
Чтобы все ето было в одном месте.
Это как жизнь: хочу и сразу….
PS скорее ты прав: надо свое – тогда и будет делать то что хотим и как.
PPPS хотя я никогда не могла понять – почему нельзя ВСЕ и СРАЗУ???
12 сентября 2007 в 1:00
То же самое, но короче: проблема не в том, что Хороший Процесс "не встраиваемый", а в том, чтобы самому(ой) найти то место, куда он встроится.
Таня, если в твоем городе нет приличной конторы, ты можешь переехать в Питер или Москву (Париж, Берлин, …)? Армия не грозит, свобода действий — полная
12 сентября 2007 в 0:05
"писать аяксы" — это такой ленивый речевой оборот =)
Про "часто не всегда" что-то не понял.
Ты, безусловно, права: свободу не дают, идиотов и анекдотов тоже много (без шуток). 90% работодателей, проектов, инженеров, кого угодно (и юзеров =) — идиоты или просто некомпетентные люди. Это и есть "не сказка". Все верно. Но лично тебе, твоим заказчикам/клиентам/юзерам/партнерам/коллегам, кто делает работу Здесь и Сейчас должно быть наплевать на эту статистику. Если ты можешь собрать лучших, умнейших и вменяемых людей, то ты можешь делать agile, стометровку за 8 секунд и тройной тулуп в гидрокостюме, если того требует задача. Важна лишь конкретная задача, команда и их конкретные особенности, а не проблемы всего человечества.
Поясню примерами.
После увольнения из компании М., я три раза находил новую работу (вплоть до текущей):
1) Это был фрилансерский заказ на интернет-магазин от одного питерского изготовителя скобяных театрально-исторических изделий. Был я, мой друг и его друг, который дизайн страничек рисовал. Т.е. было 4 человека: дизайнер, директор-программист, программист, и заказчик. И мы вчетвером работали так, как считали удобным друг для друга. Никаких корпоративных стандартов на 10000 имплоёв по всему свету, только наши собственные проблемы и попытки их решить. Это был real, не сказка.
2) Потом я нашел конторуRailsware, в которой работало сравнительно много людей: больше 30, это точно. Там тоже было не по-старпёрски: менеджеры, вменяемые люди, заставляли делать "итерации" и ежедневную очетность и переоценку планов, стратегий и тактик. Юнит-тесты (0 ошибок в тестах в репозитории — обязательно), регулярное логгирование времени, обновление планов на день на вики-страничке и т.п. И это еще при том, что работа была удаленная — в офисе никто не сидел вдесятером. Кто в Питере, кто в Москве, Львове, Севастополе, Омске.
Т.е. чуваки реально поняли, что работать надо гибко и стали так работать. И зарабатывать деньги, делать заказчиков счастливыми и все такое. Это тоже не сказка.
3) Потом я перешел в Контакт. Нас тут пять разработчиков, плюс пара девушек в техподдержке. Корпоративных стандартов нет. Кроме двух: 1) весь софт (сайт, плеер, картинки и т.п.) должен работать Быстро. 2) Интерфейс должен быть удобным и понятным. Языки программирования — пхп, перл, руби, си, дот-нет, сиплюсы. На чем хотим, на том и воротим. Ежедневные обсуждения планов и деталей реализации интерфейсов, алгоритмов и проч. Независимость разработчиков, индивидуальные задачи с минимумом контроля и overkill management-а. Кстати, из-за беспокойства за этот overkill мы очень медленно и осторожно расширяем команду. Но отличных ребят всегда с радостью возьмем, если они реально отличные. (Это между прочим.) А таких мало, к сожалению. Было б 100 незанятых гениев, нас было бы уже 100.Это тоже реал, а не сказка.
Мораль проста: то, что хороший процесс невозможно настроить в 90% идиотических организаций — это не характеристика процесса, а просто подтвержение идиотичности организации. Выращивать наркотики, петь под фанеру, продавать дешевые тумбочки — тоже приносит деньги, но мне лично не интересно. Как и неинтересно делать "интеграции" и "автоматизации", если они заставляют работать вверх ногами. Кому-то это в кайф, а кто-то не прочь "автоматизировать" и помогать Большим Компаниям (ибо деньги большие, как ни крути
, но они хотят тем не менее, улучшить процесс. Так появляются Thoughtworks — Энтерпрайз-консалтинг с человеческим лицом.
Выбор есть. Зачем идти вслед за толпой? Если бы я жил в городе Костроме, где, видимо, никаких нормальных контор нет, то я бы такую создал или, скорее всего, переехал туда, где такая есть или ее можно создать. Потому что географическая привязка — зло, если речь идет о куче идей, собственных возможностей, амбициях и интересе к жизни.
А жизнь — короткая. Её надо утилизировать с максимальным КПД.
11 сентября 2007 в 20:00
еще про "не сказку": в течении жизни проекта разработчик чувствует себя аналитиком, программистом, тестировщиком, а потом еще "программирует в ворде" и внедряет.
ЗЫ хотя, всегда есть специально обученные люди – но делать часто *не всегда* приходиться самому.
11 сентября 2007 в 19:05
аякс не язык….
ну о теории гибкой разработки, экстремальном программировании и тд – у каждого оно свое: у меня на работе пытались (сейчас бросили и разработали свою "методологию разработки") внедрить RUP……официально – мы "итеративно разрабатываем", реально: как всегда.
Поэтому скорее мы спорим не о том: что важнее (и как надо) единство языка, технологии или винегрет сего, А как в реальном (конкретно в нашем мире, нашей стране, с нашими программистами и в нашей модели разработки) все должно выглядеть? Мы может сказать что разрабатывается гибко (не важно на чем и как написано – главное легко изменяется и поддерживается), но в real – это не так……
Не в сказке же живем.
Мы ограничены – свободу программистам никто не дас, иначе получиться как в известном рассказе про 2 программистов, юриста *еще когото…..
ЗЫ программистам автоматизирующим бизнес-процессы, занимающимся интеграциями и тд
9 сентября 2007 в 22:03
Все-таки процитирую agilemanifesto.org:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
(это то, о чем я и говорю: отношения участников важнее инструментария)
Working software over comprehensive documentation
(единственный критерий правильности: работа самого приложения, а не теоретическое обоснование его безупречной работы)
Customer collaboration over contract negotiation
(опять: важнее живое сотрудничество, а не технические соглашения)
Responding to change over following a plan
(совсем банальность)
В конце: That is, while there is value in the items on the right, we value the items on the left more.
"То, что справа имеет значение, но мы большее значение придаем тому, что перечислено слева".
На брейнфаке очень тяжело писать аяксы, на джаве стократ проще. Но гораздо хуже работать с теми, кто не понимает что такое аякс, а тупо копипейстит примеры из книжки про модный язык (у которого, кстати assumption: что у вас мозг на месте и вы можете не прострелить себе ногу).
9 сентября 2007 в 22:02
"Предметная область" — ключевое слово в обсуждении "взаимозаменяемости", "продуктивности" и т.п.
Я уже сказал, что язык общего назначения требует кодирования/декодирования задачи? Если нужно пройтись по дереву и всем элементам <li> сделать сипокку, то это можно сделать двумя способами: на языке процедур потребуется сделать рекурсивную конструкцию со вспомогательной функцией, циклом и if-ом. Когда это увидит посторонний человек он увидит две функции, название одной из которых к задаче вообще отношения не имеет: traverseTree(tree). Ему придется разбираться, читать комментарии. И даже, если в комментариях задача будет описана четко, ему придется в уме ее кодировать в этот язык, чтобы понять как работает то, что лежит перед ним.
А что, если применить не язык общего назначения, а язык для данной задачи. Если задача — выбирать элементы из дерева, то нужен язык XPath, CSS selectors, regexps (или еще что-то). Эти языки можно внедрить в другой язык. Тогда для одних задач ты пишешь на одном языке, для других — на другом.
Никого не смущает, что в Джаве есть библиотеки регэкспов и XSLT? А ведь это другие языки. Совсем другие: со своими правилами. А в 3-ем ActionScript (Flash 9) есть EXML (Embedded XML). Это язык описания xml прямо в коде, плюс язык выборки (подобно XPath), интегрированный с кодом.И все это сделано не для развлечения, а потому, что эффективность работы пропорциональна адекватности языка. Чем дальше язык стоит от сути проблемы, тем больше кода и мозговой работы.
Если наиболее очевидно веб-приложение с аяксом выглядит на Рельсах, то почему бы не прикрутить JRuby? Здесь препятствием может быть производительность, но не понимание другими программистами.
Собственно, бонус-трек не об этих банальностях. А о том, как при необходимости, создавать такие языки и делать это максимально дешево.
А вот здесь всплывает пост #12, где я говорю о динамичности языка. Если язык настолько динамичный, что позволяет создавать другие языки, то это то, что доктор прописал.
Внимательно посмотрите на синтаксис выборки тегов из хтмла:
//pastie.caboo.se/54741
Он имитирует XPath и изящно интегрируется с базовым языком (рубин). В принципе, можно было сделать, как в Prototype.js: без перегрузки оператора деления и использования синтаксиса Range (две точки ".."), но тогда пришлось бы работать через сериализацию/десериализацию объектов. А если уже есть два тега a и b, то содержимое между ними в тексте: text/(a .. b), а не text.selectInRange(a.tagName, b.tagName)
Или в ActiveRecord:
class Post < ActiveRecord::Base
belongs_to :user
has_many :comments
validates_presence_of :title
after_save :save_attachments
end
Это не просто Руби, это уже язык специально для описания задачдля работы с базой данных: описание связей между объектами, валидация, дополнительные действия по специфичным событиям.
Почему Миша написал "рельсы дарят 50% процесса"? Потому что рельсы дают готовый язык, на котором вы решаете свою задачу. Т.е. нет шанса, что вы по нужде изобретете свой, неправильный язык.
Это отличает фреймворк от библиотеки (дотнет — это набор библиотек и виртуальная машина, а не фреймворк).
9 сентября 2007 в 22:02
"не "кодят", а просто подключают кучу уже написанных библиотек и технологий "— очень правильная мысль. Я хочу как-нить написать, почему софтостроение — это конструктор лего. Просто иногда кубики нужно делать свои или собирать из более мелких.
"всегда сложно выбрать что-то "сомнительное" если уже протоптана просто асфальто-бетонная дорога на какой-то одной технологии….."
Я и говорю: сложно. Плюс, нужна религия, а это вообще никак в экономических терминах не выражается.
"И кто же будет ЭТО поддерживать если вас не будет???"
Если ты знаешь, как работает Agile и прочие икспи, то тебе известен ответ. Еще раз: единство технической платформы — не ключевой момент, а в ключевой момент надо верить — agilemanifesto.
Т.е. мы все-таки с тобой спорим о том, будет ли результат работы полиглотов поддерживаемым в будущем. Я отвечу: не будет или будет в той же степени, что и результат работы моноглотов. Все зависит от документации и дизайна кода. А от конкретных языков и платформ — не зависит.
9 сентября 2007 в 21:05
"Ты сама себе противоречишь: "правильное решение архитектора: чтобы каркас был фундаментальным …". "
прав, я хотела сказать: мобильным…..
Итак,идея общая такая: в процессе разработке занимаемся интегрированием технологий, руководствуясь правилом: выгодно и правильно с точки зрения опять же разработки, и дешево с точки зрения поддержки?
Опять же джава (конкретно j2ee): на самом деле на джаве не "кодят", а просто подключают кучу уже написанных библиотек и технологий (и в внутри-джавовском смысле), пару телодвижений мышкой и танца с бубном – и "самое такое" уже реализовано.Осталось описать бизнес-логику.
К чему это я? Джава хороша не только "переносимостью"…..многие её любят из-за большого рейпозитария….от популярности (вплане для джавы все)
Вот что лучше выбрать? язык(+технологию) на котором задача решиться лучше и правильней, но:
а) найти ресурсы (в качестве раб силы)
б) найти: "что-то уже реализовано", скорее всего затруднительно
в) хз как потом все ето будет жить и как с етим работать
или вариант:
а) разработчиков – много;
б) библиотек и продуктов – очень много (IBM старается…..)
в) в поддержке довольно дешево
??? всегда сложно выбрать что-то "сомнительное" если уже протоптана просто асфальто-бетонная дорога на какой-то одной технологии…..
PS я не спорю с тобой, во многом я разделяю такое мнение…..просто реально другое: "И кто же будет ЭТО поддерживать если вас не будет???"
9 сентября 2007 в 21:04
Теперь про Процесс, Силу и Правильное распоряжение Ею.
Мы говорим о том, что сразу ничего правильного не бывает, что код — не статуя, но постоянно развивается и т.п. Вопрос: как не скатиться до Сократовского "я ничего не знаю" и делать полезные вещи в максимально верном направлении? Для этого потребуется усилие и вера (религия, библия к ней и все такое). Т.е. нечто на грани рационального.
Рекламная ссылка: agilemanifesto.org
Вкратце, во что приходится верить:
1) В то, что, не зная правильного направления, нужно как можно чаще сверяться с компасом и менять вектор. Почему это тяжело? Потому что нужно чаще принимать решения, а это нагрузка на голову. Особенно, если тот, кто должен принимать решения, привык делать это раз в месяц. Это не только нагрузка на голову, но это еще и затратно. Гораздо дешевле вложить N$ раз в квартал, чем переменное X$ с дисперсией D$ раз в неделю. Но "дешевле" лишь, если забыть о результате и о том, что он тоже чего-то стоит, и эта стоимость определяется тем, *как* он делается.
2) Что люди — не роботы и не бараны. В то, что роботов и баранов нужно избегать, вычислять и увольнять, а умных и вменяемых учить и вовлекать в общий процесс. Это тоже требует затрат времени и денег. И мозгов. Тоже трудно и неочевидно, нужно ли ("20 лет уже работаем, знаем лучше вас что и как делать").
В этой системе верований нет платформы, языков программирования, да и компьютеров вообще. Это верование касается того, что человеческая интеллектуальная производственная деятельность отличается от деятельности роботов (банкоматов, уборщиц, операторов станков и т.п.) и относиться к ней нужно по-другому: с большим упором на "интеллектуальная", а не "производство". Платформой должна быть не Джава, Юникс или Руби, а отношения между людьми в рабочем процессе.
Я продолжаю утверждать, что знание/не знание языка определяет лишь малую часть затрат при смене программиста, работающего над конкретным кодом. Большая часть затрат — въезжание в предметную область. Если язык программирования — общего назначения, то он и не мешает и не помогает въехать в предметную область: ее нужно декодировать из него. И понять, что do .. end – это как { … }, занимает очень мало времени. Гибкая философия заставляет людей делиться знанием, учить других все время. Именно XP делает возможным быструю перемену программистов и при этом окончательно снимает необходимость делать ставку на какую-то там технику.
Бонус-трек — в последнем посте.
9 сентября 2007 в 21:02
Правильно меняющийся процесс — это процесс. Неправильно меняющийся или не меняющийся процесс — тоже процесс. Есть еще бардак — вырожденная форма процесса.
Ты сама себе противоречишь: "правильное решение архитектора: чтобы каркас был фундаментальным …".
Не бывает не только "сразу правильных алгоритмов", но и архитекторов, и фундаментальных каркасов. Поэтому и завязываться на один язык/платформу — глупо. Тут, вообще есть два подхода: пытаться все сделать зашибенно универсальным сразу, либо не особо пытаться, но работать так, чтобы изменения были максимально дешевыми.
Вот, например, Джава. Она хороша тем, что заранее задумана, как переносимая: бизнес-логика — тут, машинные дела — там. Но в Сан попытались сделать максимально изолированную от особенностей ОС платформу, причем, на большой спектр задач, включая тербовательные к скорости. Что мы имеем: из-за необходимости оптимизировать скорость все равно нужно нарушать универсальность кода (или использовать внешние машинно-специфичные байндинги). Очень ярко это вылезло на мобильных платформах и сет-топ-боксах (медиа-приставках). То, что абстракции текут ни для кого не секрет. Вопрос лишь в том, насколько gracefully. Джава-инженеры позже придумали штуку JNI, которая позволяет присоединять специфичный внешний код.И люди им активно пользуются, приделывая модули на Си, Си++ и других языках (я приделывал JavaScript через С++ в рамках бизнес-задачи в Большой Компании).
Итого: абстракции текут. Поэтому используемая (ые) платформы должны давать возможность пролезать через дыры максимально сохраняя достоинство, сон и отдых. Особенно хорошо эта идея реализована в юниксах и Руби. Руби просто сделан чтоб get things done, без лишних идеологических строгостей. Поэтому он и похож на несколько языков: и на Перл, и на смолток, и на лисп. И каждый может решать задачу наиболее подходящим способом. В этом и сила. Ей нужно лишь разумно распоряжаться. О чем — далее.
9 сентября 2007 в 20:02
"дарит последнему идиоту на 50% правильный процесс"
Не понимаю что ты хочешь сказать говоря: "Если не удобен, но процесс все равно правильный — все будет также хорошо".
Ты говоришь проВеликую Программерскую Утопию: "Щааас напишем – так чтоб больше не переделывать"? Ну не бывает такого…….никогда……После сдачи проекта, пару месяцев доделываешь – так чтоб "работало как указано в ТЗ", а потом сразу переделываешь/дописываешь так чтобы "в связи с изменениями"….
Поэтому (если я правильно тебя поняла) Процесса правильного нет……ибо он меняется.
А язык (смотря какой) важен: если скажем проект написан на языке java(c# и тому подобное по синтаксису и мотивации) а какой-нить интегрированный модуль на перле (причем гуру-perl'исту: весь огромный модуль в 5 закорючках)….поддержать этот модуль java-программисту (особенно есть он "весь в джаве") будет затруднительно……точнее, скорее будет проще переписать (если немного) либо найти(!!!!) человека, работающего с перлом….
Когда пишешь для души – да, интегрируй что хочешь и как хочешь……а в общем получается: выбирается то, что дешевле в поддержке (в плане большей вероятности устранения (доделывания и тд) багов заменяемым человеком)
На мой взгляд, в этом случае правильным будет только <b>правильное решение архитектора</b>: чтобы каркас был фундаментальным и логика не железная (легко поддающаяся переделыванию), но не абсолютной. Ибо универсального ПО не бывает. Особенно если ты занимаешься Автоматизацией и в таком духе.
Поправьте меня.
9 сентября 2007 в 1:02
Приведу два примера:
1) Компания М., где я работал, делает софт (Большой Софт) так, что там уже джава-не джава, ничего не спасёт. Т.е. там есть куча программистов, которые, может и поймут, что написали другие, но на уровне "скобочки знакомые". Сам по себе язык (знакомый/не знакомый) поможет понять чужой незнакомый код максимум на 1%. Понимаение кода лежит в организационном поле. Небольшая команда, в которой народ делится достижениями со всеми коллегами, находится в курсе происходящего и не выпадает из фокуса. Например, в студии лебедева нет стандарта на язык: там бывают жуткие вещи: parser, php, xslt, java, .NET, perl. Иногда в одном проекте. Но знакомый мне техдиректор устраивал просветительские часы раз в неделю, чтобы народ не терялся в пространстве. И все работало!
2) Компания Thoughtworks серьезно занимается Рубином и славится своими великолепными мастерами Интерпрайза: Мартином Фаулером (книга "Рефакторинг", "Паттерны дизайна интерпрайзных приложений"), Джеем Филдсом и другими деятелями (там еще наш соотечественник есть непомню-как-его-звать). Они занимаются консультированием больших компаний и сами разрабатывают софт. Джаву и Руби используют бок-о-бок.
Если сократить все, что я сказал выше, то получится вот что: сам по себе язык никакого стратегического преимущества не дает. Преимущество дает *процесс*. Если язык удобен для данного процесса, то все будет окей. Если не удобен, но процесс все равно правильный — все будет также хорошо. А если язык суперский, но процесс и порядок отсутствует, то все будет плохо. Ну, и, разумеется, с брейнфаком процесс построить будет очень тяжело.
Примерно это недавно Миша Клишин озвучил:
//www.novemberain.com/2007/9/2/rails-suprimacy-...
8 сентября 2007 в 21:04
Олег, так красиво все рассказываешь……
в жизни то не все так просто: интегрирование…..если выигрываешь в качестве, проигрываешь в поддержке: найти (для примера) того кто гуру джавы и руби-нинзя не так просто……..
а в интегрированном проекте уже это является важным(!) условием.
ЗЫ задача программиста: писать код (при желании рабочий) и (!) чтоб другие менее гениальный программисты всепонимали что ты написал
поддержка
8 сентября 2007 в 15:02
* это я не призываю кого-то к чему-то, а просто обрисовываю чем занято прогрессивное человечество в свободное от ынтырпрайзного софтоделания время.
8 сентября 2007 в 15:01
Dave Thomas считает, что разделение языков на "компилированные" и "интерпретируемые" — слишком поверхностно. Он предлагает разделение на "динамические" и "статические". В категорию динамических, соответственно, попадают и Смолток, и Лисп. Замечу, что есть реализация Смолтока (Strongtalk VM), которая работает со скоростью Джавы, а лисп вообще можно выполнять со скоростью света (при желании).
Мне кажется, что есть два параметра: степень динамичности языка и скрытые накладные расходы на эту динамику. В руби динамичность высока, но и расходы велики. В смолтоке динамичность тоже высокая, но расходы существенно ниже. В Си динамичности просто нет, зато расходы тоже нулевые (это макросы для асма, все-таки). В Джаве есть чуть большая динамика (рефлексия, то-се), но при этом куча бюрократических ограничений, не связанных с оптимизацией. И расходы на динамику — минимальные.
Мое личное мнение таково, что, принципиально, эти два параметра не зависят друг от друга (по крайней мере, до тех пор, пока никто не достиг совершенства в создании виртуальных машин для динамических языков). Первый — динамика — определяется абстрактным дизайном языка (без учета деталей реализации машины). Второй — расходы — определяется эффективностью выполнения языка.
С учетом вышесказанного, получаем вот что:
1) Руби — замечательный, разносторонний динамичный язык, но виртуальная машина MRI 1.8 ни к черту не годится. YARV 1.9 на 70% быстрей, но можно еще лучше без потерь в функциональности языка (пример Strongtalk тому подтверждение).
2) Джава — довольно быстрая виртуальная машина, но бюрократические и родовые травмы искусственно занижают уровень динамики. (Который мог быть выше при той же производительности; что и исправляют JRuby).
Теперь очевидно, почему все большее количество людей фтыкает язык Руби и машина Джава. Потому что первое — красивое и удобное, а второе — быстрое. Поэтому направление деятельности у нас такое: построить быструю машину для Руби и приделать к JVM более приличные языки (иногда эти задачи пересекаются). А не наоборот или как-то иначе.
С дотнетом та же история, что и с джавой.
8 сентября 2007 в 14:04
Вот когда доделают JRuby, вот тогда и можно будет говорить о пригодности его использования в продакшене.
Не, я согласен. Домашний проект можно набить на чём угодно. Но если это будет крутиться где-то там, где за стабильность будут платить деньги – увольте, JRuby там у меня не будет. По крайней мере сейчас. Хотя, лично я считаю, что со временем, Ruby способен заменить Java во многих проектах. Главное, чтобы его не постигла участь других скриптовых языков: мир развивается, а возможности языка уже достигли своих пределов. В своё время Perl тоже превозносили на пьедестал. Но появились виртуальные машины, нативные (для окружения) скриптовые языки, работающие не через CGI-интерфейс, и для Perl'а вырисовались довольно чёткие границы применимости. Но в своей области он до сих пор рулит. Я лично я не вижу смысли переписывать скрипты автоматизации выполнения с Perl'а на Ruby, только потому что "Ruby – крут".
А вот с компилированными языками сравнивать языки интерпретируемые глупо. Всегда было смешно, когда сравнивают C/C++ и Java.
У компилированный свои плюсы и минусы. У интерпретируемых – свои. И большинство из них не как не зависит от той или иной реализации (языка).
8 сентября 2007 в 7:03
Ну, насчет джавы. Джава как платформа,вроде бы не подыхает и многих даже по скорости устраивает. А вот язык — да. Не зря майкрософты стали делать дотнет многоязычным.
8 сентября 2007 в 7:01
Иван, таки да, почти для всех. Потому кроме интерпретатора 1.8.6 уже есть JRuby который скоро станет совсем-совсем правильным языком для JVM (то бишь с компиляцией в байткод) и скоро выйдет IronRuby (тоже самое для .NET). А это уже бОльшая часть веба и "автоматизации бизнес-процессов".Остаются C\C++ (производительность), Objective-C(привет яблочным друзьям)ну и всякая экзотика – Erlang, LISP, Haskell и тп.
В итоге через год-полтора (когда реализации J\IronRuby доведу до ума), я вообще не вижу смысла вязыках С#, VB, Java. А это – около трети всех проектов.
7 сентября 2007 в 23:05
Кстати, недавно где-то слышал про JavaFX… Не знаю, насколько этот продукт готов для продакшена, но вроде это именно связка Java +AJAX. На выходных посмотрю, может подробнее напишу.
7 сентября 2007 в 23:02
хм)из за долгих поисков ТОГО что можно использовать для данной задачи под джаву пришла к выводу:что либо веб (аякс и тд) не для джавы (жуть как неудобно) либо действительно нужно заниматься интегрированием…..
Олег Андреев, почитала что JRuby…..незнаю…..у меня сейчас есть время – посмотрю: интегрирую – расскажу…..как все живет…
ЗЫ пасиб всем за ответы
7 сентября 2007 в 0:02
Поэтому я и написал "возможно, стоит запустить" (и посмотреть как пойдет). Для аяксов, рельсы — самый прямолинейный путь.
Иван: а что вы знаете о Руби? =)
6 сентября 2007 в 23:04
=))
6 сентября 2007 в 20:01
У меня складывается ощущение, что для некоторых Ruby становиться панацеей для решения практически любых задач.
6 сентября 2007 в 20:00
на самом деле проблемы в JRuby есть, и они решаться с выходом компилятора (то бишь в 1.1), но этого надо ждать. К тому же пока (до выхода компилятора) JRuby тормознее чем интерпретатор 1.8.6, а последний тоже не ахти какой быстрой.Так что по-любому придется ключевые по производительности места переписывать на Java или вообще на C.
6 сентября 2007 в 13:01
GWT не юзал, но говорят, что он неплохой. Однако. Я плохо отношусь к подобного рода кодогенерации. Возможно, стоит запустить JRuby и поднять Rails. Далее — без проблем со спрингом делаем веб-апп с аяксами на джава-сервере.
Т.е. JRuby для этого и разрабатывают.
Использование библиотек Джавы в руби — прозрачно и без проблем, насколько я знаю (игрался чуток).