Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 102
Надо бы заняться изучением Ruby, да все руки как-то недоходят, а ведь хочется попробовать =)
Позволю себе не согласиться с этим высказыванием. Отличная разминка для ума — выучить что-нибудь новенькое, плюс кругозор расширяет. Не зря рекомендуют хотя бы раз в полгода учить новый язык/технологию.
Говорят, чтобы развиваться, программист должен изучать минимум один язык в год.
Почему не два? Ну что бы ещё быстрее развиваться.
Развиваться можно по разному. Если ко мне придут 2 человека, один из которых 4 последних года учил PHP, Ruby, Python, Perl; а второй — алгоритмы, проблемы многопоточности, устройство виртуальной машины, поисковую оптимизацию — я скорее возьму на работу второго. Просто так учить язык имеет мало смысла — сравните изучение lisp для настройки emacs & вместе с прочтением sicp.
Я потому и написал — язык/технологию. Сам по себе язык — это ерунда, после первых двух все остальные похожи друг на друга (ну да, есть сильно отличающиеся от классических наследников C — любой из функциональных, но это отдельный разговор). Обычно изучение языка влечет за собой изучение библиотек, практик программирования, подходов к организации кода и так далее. Поставив перед собой цель решить практическую задачу используя новую технологию — можно освоить все то, что Вы перечислили :-)
Стив Джобс очень хорошо про это сказал:
None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac…
None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac…
> Код каждого установленного плагина предварительно изучается.
О да, открытые классы могут преподнести много сюрпризов)
О да, открытые классы могут преподнести много сюрпризов)
но делаете ли вы это каждый раз? Я redcloth не рискну перепроверять.
Я — нет) Хоть и считаю Ruby языком красивым, но не подходящим для чего-то большого и серьёзного.
Мне вот стало интересно, Basecamp вы считаете маленьким и несерьезным?
Да. Приложение довольно простое + очень ограниченное для пользователя. Ruby хорош пока вы сидите внутри Rails — вы знаете, где у вас контроллеры, где модели — всё очень прозрачно благодаря его структуре, если ваш проект вылезает за эти рамки — лучше взять статически типизированный язык.
Какое отношение статическая типизация имеет к выходу за пределы Rails?
Вообще, я так понимаю, вы предлагаете писать крупные приложения без использования фреймворков вообще, потому как когда приложение вырастает из их возможностей, это ведет к сложностям? Я правильно понял?
Вообще, я так понимаю, вы предлагаете писать крупные приложения без использования фреймворков вообще, потому как когда приложение вырастает из их возможностей, это ведет к сложностям? Я правильно понял?
Статическая типизация, кроме того, что она даёт колоссальные возможности для рефакторинга кода обеспечивает ещё так называемые contracts. Рассуждать здесь об этом долго — можете почитать, почему это появится в JavaScript 2.
Всё зависит от приложения. При работе с Java в 99% случаев в основе лежит IoC-контейнер, а уже он управляет всеми зависимостями(создаёте вы IDE, SOA или Web — они будут разные). В Rails же, насколько я помню даже в интеграции одного приложения в другое встречаются проблемы: есть Engines, но DHH вроде бы категорически против таких подходов.
Всё зависит от приложения. При работе с Java в 99% случаев в основе лежит IoC-контейнер, а уже он управляет всеми зависимостями(создаёте вы IDE, SOA или Web — они будут разные). В Rails же, насколько я помню даже в интеграции одного приложения в другое встречаются проблемы: есть Engines, но DHH вроде бы категорически против таких подходов.
Простите, был напуган. Ваш ответ заставил пойти почитаться, спасибо большое.
Теперь могу попробовать по существу. Мне правда интересно разобраться в вопросе (найдете время — буду рад).
Contracts — понятно. Рефакторинг тоже, если речь об автоматических рефакторингах (обнаружению «Bad Smells in Code»). Правильно ли я понял?
Еще мне интересно вот что: на Java я не писал ничего серьезного никогда, поэтому не очень верится про 99% IoC. Это действительно стандарт де-факто? Ведь и Ruby в принципе позволяет написать реализацию контейнера, хотя это уже не рельсы совсем получатся…
Я бы рискнул предположить, что Rails подходят даже для больших приложений, но вполне определенного типа: веб-сервисов (ведь для этого он и создавался).
В качестве примера большого приложения привел-бы yellowpages.com и github.com (примеры с rubyonrails.com).
Жаль last.fm не на Rails) идеально бы подошел как пример)
Теперь могу попробовать по существу. Мне правда интересно разобраться в вопросе (найдете время — буду рад).
Contracts — понятно. Рефакторинг тоже, если речь об автоматических рефакторингах (обнаружению «Bad Smells in Code»). Правильно ли я понял?
Еще мне интересно вот что: на Java я не писал ничего серьезного никогда, поэтому не очень верится про 99% IoC. Это действительно стандарт де-факто? Ведь и Ruby в принципе позволяет написать реализацию контейнера, хотя это уже не рельсы совсем получатся…
Я бы рискнул предположить, что Rails подходят даже для больших приложений, но вполне определенного типа: веб-сервисов (ведь для этого он и создавался).
В качестве примера большого приложения привел-бы yellowpages.com и github.com (примеры с rubyonrails.com).
Жаль last.fm не на Rails) идеально бы подошел как пример)
не согласен с п.10
использование STI часто не имеет более вменяемых и удобных альтернатив.
плюс еще можно добавить «избегайте имен переменных из одной буквы»
использование STI часто не имеет более вменяемых и удобных альтернатив.
плюс еще можно добавить «избегайте имен переменных из одной буквы»
В оригинале Matt предлагает вместо STI нагенерить обычных моделей и подключать к ним нужные модули, аргументируя тем, что c STI мы накрепко связываем 2 модели (ну как и в любом наследовании).
Но на мой взгляд всё это не так плохо, на самом деле STI — очень удобная абстракция, можно вообще забыть о том, что данные хранятся в одной таблице, рельсы сами позаботятся о разграничении доступа к разным моделям из одной таблицы. Так что пожалуй зря Matt так бузит на STI, STI очень выручает иногда…
Но по остальным пунктам я с ним согласен, особенно п.14, про тест на каждый баг.
Но на мой взгляд всё это не так плохо, на самом деле STI — очень удобная абстракция, можно вообще забыть о том, что данные хранятся в одной таблице, рельсы сами позаботятся о разграничении доступа к разным моделям из одной таблицы. Так что пожалуй зря Matt так бузит на STI, STI очень выручает иногда…
Но по остальным пунктам я с ним согласен, особенно п.14, про тест на каждый баг.
> Те люди, которые начинали программировать с C, C++ или Java, обнаружат в Ruby абсолютно другой (и более правильный!) подход к ОО-дизайну, а в Rails — много интересных решений, которые необходимо понять и осознать. И хотя изучение Ruby заняло у меня много времени (и я уверен, что еще очень многое предстоит узнать), я люблю эту технологию и не собираюсь возвращаться назад.
вот только зачем нужно переходить с Java на Ruby и переучиваться «много времени», когда есть Groovy/Grails?
вот только зачем нужно переходить с Java на Ruby и переучиваться «много времени», когда есть Groovy/Grails?
Такое впечаление, что минусующие Groovy никогда не пробовали :(
Минусущие, с высокой вероятностью пробовали только PHP. Перейдя на Раби они ошалели от ООП возможностей. Те кто писал на Джава никаких таких эмоций не испытывают. Они видят в Раби просто новый несложный язык заменяющий PHP с тривиальными ООП возможностями и фреймуорк, который позволяет быстро писать несложные приложения. Всё это в тех или иных видах давно было в мощных языках. Раби скорее элегантный баланс чем новизна.
То есть, хотите сказать, что Ява-девелопер, узнав как работают методы и примеси в Руби, не подумает, что на Руби надо думать по-другому? Или в Ява-программисты часто юзают утиную типизацию?
Руби — динамический язык программирования. И упомянутые C++, Java и PHP программисты действительно найдут для себя много новизны, если будут настойчивы и разберутся в нем дальше синтаксиса.
Несложность Руби — сомнительная вещь. Да, мы уже не управляем указателями вручную, мы не оперируем с памятью. Но если мы не знаем, что есть указатель, и как влияет то или иное действие на память, то мы получаемся плохими Руби-программистами.
Итого: я не согласен, потому что:
1) Яверы испытывают эмоции от Руби
2) Руби — не несложный язык
3) Учитывая, что Руби — ровесник Явы, то, мне кажется, слово «новизна» к нему применимо
Руби — динамический язык программирования. И упомянутые C++, Java и PHP программисты действительно найдут для себя много новизны, если будут настойчивы и разберутся в нем дальше синтаксиса.
Несложность Руби — сомнительная вещь. Да, мы уже не управляем указателями вручную, мы не оперируем с памятью. Но если мы не знаем, что есть указатель, и как влияет то или иное действие на память, то мы получаемся плохими Руби-программистами.
Итого: я не согласен, потому что:
1) Яверы испытывают эмоции от Руби
2) Руби — не несложный язык
3) Учитывая, что Руби — ровесник Явы, то, мне кажется, слово «новизна» к нему применимо
Верно, Раби не так и прост, если писать на нём профессионально. Я хотел сказать, что человек, по большому счёту хорошо понимающий Джава, Шарп или C++, и знающий не один язык, достаточно быстро поймёт принципы Раби. И они никак не шокируют его своей новизной. Но, подходы к разработке командой там будут действительно несколько другие.
Динамические языки, это вообще очень опасная вещь. Они дают мнимую лёгкость и свободу если ты один в поле воин. Но выставляют кучу заточенных прутьев, если ты в поле воин не один. Вот эту мысль я и оттенил. Чуть грубовато. :-)
Если человек писал на PHP и через его призму познавал тонкости ООП, то он будет в восторге от возможностей языка Раби. Если он хорошо понимает Джава, то он легко смоделирует подобный интерпретируемый язык. Но не будет делать этого без необходимости. Ну просто потому, что он уже, скорее всего, наелся по уши динамической свободой и достаточно хорошо понимает те опасности которая она несёт. Именно поэтому, Раби, будучи практически ровестником Джавы, даже близко не приблизился к её, Джава, промышленной популярности.
Динамические языки, это вообще очень опасная вещь. Они дают мнимую лёгкость и свободу если ты один в поле воин. Но выставляют кучу заточенных прутьев, если ты в поле воин не один. Вот эту мысль я и оттенил. Чуть грубовато. :-)
Если человек писал на PHP и через его призму познавал тонкости ООП, то он будет в восторге от возможностей языка Раби. Если он хорошо понимает Джава, то он легко смоделирует подобный интерпретируемый язык. Но не будет делать этого без необходимости. Ну просто потому, что он уже, скорее всего, наелся по уши динамической свободой и достаточно хорошо понимает те опасности которая она несёт. Именно поэтому, Раби, будучи практически ровестником Джавы, даже близко не приблизился к её, Джава, промышленной популярности.
Затем, что:
1) Groovy/Grails менее популярны, и, что более важно, у них ниже динамика набора популярности. А популярность — это комьюнити, возможность спросить непонятное, это существование готовых хостингов (много вы знаете хостингов на grails?) т. д.
2) Groovy требует Java-окружения, которое более тяжеловесно, чем Ruby-окружение. А это в том числе означает дополнительные нагрузки для хостера и, как следствие, более дорогой хостинг. Можно, конечно, использовать colocation или VPS, но это ещё дороже.
1) Groovy/Grails менее популярны, и, что более важно, у них ниже динамика набора популярности. А популярность — это комьюнити, возможность спросить непонятное, это существование готовых хостингов (много вы знаете хостингов на grails?) т. д.
2) Groovy требует Java-окружения, которое более тяжеловесно, чем Ruby-окружение. А это в том числе означает дополнительные нагрузки для хостера и, как следствие, более дорогой хостинг. Можно, конечно, использовать colocation или VPS, но это ещё дороже.
1) www.indeed.com/jobtrends?q=ruby%2C+groovy&l=&relative=1 динамика сравнимая.
2) VPS стоит нынче 20$ за 256MB и спокойно тянет несколько Grails приложений.
2) VPS стоит нынче 20$ за 256MB и спокойно тянет несколько Grails приложений.
1. у groovy достаточно большое комьюнити, где можно спросить непонятное.
2. уж с чем-чем, а с хостингом дела у java, а, следовательно, и grails куда лучше.
3. как платформа java на голову выше ruby, с этоим спорить бессмысленно. полезных плагинов к rails, наверное, побольше, но опять же кто ручается за качество их кода и безглючность? ;)
2. уж с чем-чем, а с хостингом дела у java, а, следовательно, и grails куда лучше.
3. как платформа java на голову выше ruby, с этоим спорить бессмысленно. полезных плагинов к rails, наверное, побольше, но опять же кто ручается за качество их кода и безглючность? ;)
я только не понял, при чем тут «закоренелое Java-мышление»? где описано, что это такое и какое оно отношение имеет к вышеприведенным пунктам :)
Ну что вы, всё связанное с Java это же такое монстроузное старьё & not cool!
Меня всегда интересовало, почему рубисты выбирают для своих нападок Java, когда им даже PHP & Python обогнать особо не свитит. Прямо мания величия и элитарности.
Меня всегда интересовало, почему рубисты выбирают для своих нападок Java, когда им даже PHP & Python обогнать особо не свитит. Прямо мания величия и элитарности.
J2EE is dead — long live JEE. В 5 версии JEE давольно юзабельный(Seam Framework), а одной из реализаций 6 версии, которая выйдет к концу года будет Spring. Ещё есть всякие Guice, Wicket, Grails. Многие, кто ругают J2EE насмотрелись подобных роликов и толком не понимают о чём пишут. Судя по вашему комментарию — вы тоже.
Скринкаст смотрел — бестолковый. Java использовалась вообще без каких либо фреймворков, в отличие от других языков. Вот это уж действительно скринкаст от тролля, хоть и весёлый — но пустой.
Скринкаст смотрел — бестолковый. Java использовалась вообще без каких либо фреймворков, в отличие от других языков. Вот это уж действительно скринкаст от тролля, хоть и весёлый — но пустой.
Я использую J2EE каждый день. Частично, возможно, из-за того что это старая версия, но очень часто хочется плеваться. В основном от J2EE, но иногда и от самой Java. Простейшие операции, например join коллекции строк через запятую, делаются с неприлично большим объёмом кода (вобще работа с коллекциями с стандартной библиотеке очень плоха (один перебор Map чего стоит) хотя это и решается частично сторонними библиотеками). Очень невменяемые сообщения о ошибках (например NullPointerException, ClassCastException — из-за чего null pointer, от чего к чему class cast). Именования — почему у ArrayList метод добавить называется add, а Map — put? И это я только самое надоедливое привёл.
От старой J2EE можно плелваться(даже нужно =)), особенно если это IBM или SAP — там свои «ништяки». По Java — почитайте Better Java от Джошуа Блоха, её надо уметь готовить. Почему add/put — почитайте документацию. Для коллекций есть замечательная библиотека google collections.
Java не идеальна, никто не спорит.
Java не идеальна, никто не спорит.
Понятно что ничто не идеально. Просто в данном контексте — почему рубисты критикуют ява — потому что руби является в некотором смысле антиподом ява.
Приведённая примеры в контексте руби — коллекции там реализованы, имхо, на 5+. Не создаются лишние сложности с именами — и в массив и в хэш данные добавляются (точнее это один из вариантов) через [], коллекции реализуют два метода length и size — не ошибёшься (и низа что не поверю что у кого-то это создало путаницу).
Руби это простота и красота результирующего кода за счёт некоторого усложнения языка, в то время как ява — многословность и как следствие усложнённость из-за невыразительности самого языка.
Ява неспешно меняется в лучшую сторону, 1.5 вобще можно назвать прорывом, но по сравнению с той же scala всё равно, имхо, выглядит многословным атавизмом.
Приведённая примеры в контексте руби — коллекции там реализованы, имхо, на 5+. Не создаются лишние сложности с именами — и в массив и в хэш данные добавляются (точнее это один из вариантов) через [], коллекции реализуют два метода length и size — не ошибёшься (и низа что не поверю что у кого-то это создало путаницу).
Руби это простота и красота результирующего кода за счёт некоторого усложнения языка, в то время как ява — многословность и как следствие усложнённость из-за невыразительности самого языка.
Ява неспешно меняется в лучшую сторону, 1.5 вобще можно назвать прорывом, но по сравнению с той же scala всё равно, имхо, выглядит многословным атавизмом.
красота кода есть в groovy ;)
Вообще то здесь спор не ruby vs все языки реализованные на JVM (включая jruby). А в groovy меня меня немного коробит попытка сделать ruby с java синтаксисом. ИМХО подход «и синтаксис взять оттуда что индусы быстрее переучивались» заранее ущербен. Хотя я groovy сильно не интересовался, рассуждаю заочно, и вполне могу нести бред :).
В Scala всё же слишком много хороших идей. Это, наверное, её второй минус после trade-off'ов при интеграции с Java.
Коллекции в Java/Scala всё же типизированные и более продвинутые. Не хватает замыканий для однострочников? Может появятся в 7 версии(http://functionaljava.org/examples).
Я вообще сомневаюсь в появлении лучшей Java, хотя будущее вижу где-то между Jetbrains MPS, Scala & Ruby.
Коллекции в Java/Scala всё же типизированные и более продвинутые. Не хватает замыканий для однострочников? Может появятся в 7 версии(http://functionaljava.org/examples).
Я вообще сомневаюсь в появлении лучшей Java, хотя будущее вижу где-то между Jetbrains MPS, Scala & Ruby.
скала слишком сложна, чтобы стать новой java, да и руби обладает несколько иным синтаксисом.
Тут в чём дело… Все согласны на том, что нужен новый уровень абстракции(DSLs). И есть 3 пути:
1) MPS
+ java language, любые DSLs, IDE
— Generative programming
2) Ruby/Groovy
+ простота
— Dynamic lang(скорость, IDE, контракты)
3) Scala
+ Полноценный Java-заменитель, много хороших идей(FP, Actors Model)
— Сложность
Мне лично первый подход кажется наиболее очевидным. Jetbrains сейчас начали выкладывать документацию и я планирую всерьёз поковыряться с MPS. Если всё это будет достаточно просто, то я думаю, что она сможет «выстрелить», я имею ввиду создание DSLs, работа с ними там на высоте.
1) MPS
+ java language, любые DSLs, IDE
— Generative programming
2) Ruby/Groovy
+ простота
— Dynamic lang(скорость, IDE, контракты)
3) Scala
+ Полноценный Java-заменитель, много хороших идей(FP, Actors Model)
— Сложность
Мне лично первый подход кажется наиболее очевидным. Jetbrains сейчас начали выкладывать документацию и я планирую всерьёз поковыряться с MPS. Если всё это будет достаточно просто, то я думаю, что она сможет «выстрелить», я имею ввиду создание DSLs, работа с ними там на высоте.
1) с MPS'ом не знаком, и, честно говоря, пока не очень представляю, зачем он нужен. Да и насчёт DSL тоже.
2) важно отметить, что в плане перехода с java и интеграцией с ней groovy — однозначный лидер, даже 'родной' javafx куда дальше. Что насчёт скорости — так над этим работа идёт, и весьма успешно, как я считаю. Что такое контракты — я, увы, не знаю. А вот поддержка в IDE уже весь прилична(именно в плане динамики) и активно улучшается.
3) Сложность, боюсь, всё сильно усложняет, втч поддержку в IDE
2) важно отметить, что в плане перехода с java и интеграцией с ней groovy — однозначный лидер, даже 'родной' javafx куда дальше. Что насчёт скорости — так над этим работа идёт, и весьма успешно, как я считаю. Что такое контракты — я, увы, не знаю. А вот поддержка в IDE уже весь прилична(именно в плане динамики) и активно улучшается.
3) Сложность, боюсь, всё сильно усложняет, втч поддержку в IDE
По поводу MPS — сам проект уже не молодой, сейчас как я понимаю проходит последнюю обкатку и готовится к выходу на публику. JB недавно портировали его на платформу IDEA & написали на нём свой новый трекер. Ну Grails — по сути DSL над Spring, Hibernate… MPS будет выполнять примерно тоже самое, только другим подходом.
В минусах я писал исключительно _нерешаемые_ проблемы. Производительность и поддержка IDE у динамических языков существенно ниже. Планка есть и её никуда не убрать — Smalltalk, Self: Sun через всё это уже прошла. Про контракты — можно почитать спеку ES4, там написано почему в JavaScript добавят опциональное статическое типизирование.
Усложняет, но не делает невозможным — синтаксический анализ статически-типизированного языка на порядок проще и перспективнее. Впрочем, то что мы сейчас имеем для Java вряд ли появится для какого либо другого языка.
В минусах я писал исключительно _нерешаемые_ проблемы. Производительность и поддержка IDE у динамических языков существенно ниже. Планка есть и её никуда не убрать — Smalltalk, Self: Sun через всё это уже прошла. Про контракты — можно почитать спеку ES4, там написано почему в JavaScript добавят опциональное статическое типизирование.
Усложняет, но не делает невозможным — синтаксический анализ статически-типизированного языка на порядок проще и перспективнее. Впрочем, то что мы сейчас имеем для Java вряд ли появится для какого либо другого языка.
Вы очень категорично пишете, но по сути, вы просто не разобрались с коллекциями в Джава. Они очень грамотно и продуманно сделаны. Если вам там что-то не нравится, то прежде надо постараться понять почему так сделано и какие цели преследовались.
К примеру ArrayList реализует интерфейс Collection. И потому там стоит add, а Map реализует интерфейс Hashtable и потому, там стоит put. Это по сути разные интерфейсы. В одном случае мы имеем дело просто с занесением элемента, а в другом — занесение элемента с ключём. И правильно, что методы называются по разному. Это помогает избежать путаницы. Ибо принцип работы с ними совершенно разный.
NullPointer всегда прослеживается трейсом до того места, где это возможно, вплоть до указания переменной. Если у вас сама коллекция не создана, то и будет указана строчка. Также и с ClassCast… Если вы объявили коллекцию типизированной, то вам ещё при компиляции будет ошибка. Если нет — покажется фактический тип.
Почитать бы вам букварь, прежде чем Java ругать. Ругать дело нехитрое.
К примеру ArrayList реализует интерфейс Collection. И потому там стоит add, а Map реализует интерфейс Hashtable и потому, там стоит put. Это по сути разные интерфейсы. В одном случае мы имеем дело просто с занесением элемента, а в другом — занесение элемента с ключём. И правильно, что методы называются по разному. Это помогает избежать путаницы. Ибо принцип работы с ними совершенно разный.
NullPointer всегда прослеживается трейсом до того места, где это возможно, вплоть до указания переменной. Если у вас сама коллекция не создана, то и будет указана строчка. Также и с ClassCast… Если вы объявили коллекцию типизированной, то вам ещё при компиляции будет ошибка. Если нет — покажется фактический тип.
Почитать бы вам букварь, прежде чем Java ругать. Ругать дело нехитрое.
Экспертом по Java я не являюсь, не спорю, вполне возможно с чем-то не до конца разобрался, но букварь я всё же осилил.
> Они очень грамотно и продуманно сделаны. Если вам там что-то не нравится, то прежде надо постараться понять почему так сделано и какие цели преследовались.
Давайте пример — есть коллекция объектов типа Person, у них есть name. Частая практическая задача: получить их список имён через запятую — как это сделать коротко и просто в Java?
> К примеру ArrayList реализует интерфейс Collection. И потому там стоит add, а Map реализует интерфейс Hashtable и потому, там стоит put. Это по сути разные интерфейсы. В одном случае мы имеем дело просто с занесением элемента, а в другом — занесение элемента с ключём. И правильно, что методы называются по разному. Это помогает избежать путаницы. Ибо принцип работы с ними совершенно разный.
Понятно что интерфейсы разные, но по моему это паранойя — ни могу придумать ни одной ситуации когда может возникнуть путаница.
> NullPointer всегда прослеживается трейсом до того места, где это возможно, вплоть до указания переменной.
Стэк трэйс это хорошо, но почему нельзя было сделать по человечески — указать сразу имя объекта и метод который пытались вызвать? И ещё от стэк трэйса мало пользы если используется сторонняя закрытая библиотека.
> Также и с ClassCast… Если вы объявили коллекцию типизированной, то вам ещё при компиляции будет ошибка. Если нет — покажется фактический тип.
Я обеими руками за типизированные коллекции. Вот только очень невнятные сообщения о ошибках приведения это мало оправдывает
> Они очень грамотно и продуманно сделаны. Если вам там что-то не нравится, то прежде надо постараться понять почему так сделано и какие цели преследовались.
Давайте пример — есть коллекция объектов типа Person, у них есть name. Частая практическая задача: получить их список имён через запятую — как это сделать коротко и просто в Java?
> К примеру ArrayList реализует интерфейс Collection. И потому там стоит add, а Map реализует интерфейс Hashtable и потому, там стоит put. Это по сути разные интерфейсы. В одном случае мы имеем дело просто с занесением элемента, а в другом — занесение элемента с ключём. И правильно, что методы называются по разному. Это помогает избежать путаницы. Ибо принцип работы с ними совершенно разный.
Понятно что интерфейсы разные, но по моему это паранойя — ни могу придумать ни одной ситуации когда может возникнуть путаница.
> NullPointer всегда прослеживается трейсом до того места, где это возможно, вплоть до указания переменной.
Стэк трэйс это хорошо, но почему нельзя было сделать по человечески — указать сразу имя объекта и метод который пытались вызвать? И ещё от стэк трэйса мало пользы если используется сторонняя закрытая библиотека.
> Также и с ClassCast… Если вы объявили коллекцию типизированной, то вам ещё при компиляции будет ошибка. Если нет — покажется фактический тип.
Я обеими руками за типизированные коллекции. Вот только очень невнятные сообщения о ошибках приведения это мало оправдывает
1.
2. Ситуации сплошь и рядом. Алгоритм опирающийся на хеш, как правило отличается от алгоритма, предполагающего, что данные лежат в коллекции. И стало быть методы доступа надо отличать. То есть у них как правило будет разное алгоритмическое окружение
3. Он и показывает всё что вы сказали. Если никто по незнанию не перхватил исключение и не убил его трейс. И неважно открытая библиотека или закрытая. Хорошая также ещё допишет рекомендацию куда посмотреть и что предпринять. Spring к примеру.
4. Опять же — быть может в вашем случае кто-то их перехватывает и к примеру прибивает вывод.
Collection<Person> persons = ...; // заполняем коллекцию
for( Person person : persons ) {
System.out.println( person.getName() + "," );
}
// ** Убрать последнюю запятую если не нужна
2. Ситуации сплошь и рядом. Алгоритм опирающийся на хеш, как правило отличается от алгоритма, предполагающего, что данные лежат в коллекции. И стало быть методы доступа надо отличать. То есть у них как правило будет разное алгоритмическое окружение
3. Он и показывает всё что вы сказали. Если никто по незнанию не перхватил исключение и не убил его трейс. И неважно открытая библиотека или закрытая. Хорошая также ещё допишет рекомендацию куда посмотреть и что предпринять. Spring к примеру.
4. Опять же — быть может в вашем случае кто-то их перехватывает и к примеру прибивает вывод.
1.
Collectionpersons = ...; // заполняем коллекцию
for( Person person: persons ) {
System.out.println( person.getName() + "," );
}
// ** Убрать последнюю запятую если не нужна
Вот это я и называю кучей кода :). Сравните с реализацией на руби:
persons.map(&:name).join ", "
Из типизированных таже scala может выразить это почти с краткостью руби.
2. Ситуации сплошь и рядом. Алгоритм опирающийся на хеш, как правило отличается от алгоритма, предполагающего, что данные лежат в коллекции. И стало быть методы доступа надо отличать. То есть у них как правило будет разное алгоритмическое окружение
Вы просто не сможете их перепутать — один требует два параметра, второй один. Вобще здесь спорить бесполезно, это вопрос скорее вкуса. Добавлю только, что алиасы методов в руби, когда метод может носить несколько названий, ИМХО очень правильная вещь. Можно до хрипоты спорить что length и size это семантический разные вещи, но то что можно вызывать любой просто удобно, не нужно лишний раз задумыватьсь, лезть в справку, или смотреть контекстные подсказки.
3. Он и показывает всё что вы сказали. Если никто по незнанию не перхватил исключение и не убил его трейс. И неважно открытая библиотека или закрытая. Хорошая также ещё допишет рекомендацию куда посмотреть и что предпринять. Spring к примеру.
Возможно в новых версиях ява так и есть. В моём случае сообщения, к сожалению, по чеховски кратки — такая то строка в таком-то файле, которого у меня нет :(
4. Опять же — быть может в вашем случае кто-то их перехватывает и к примеру прибивает вывод.
Опять же — ClassCast — и ни слова больше.
Collectionpersons = ...; // заполняем коллекцию
for( Person person: persons ) {
System.out.println( person.getName() + "," );
}
// ** Убрать последнюю запятую если не нужна
Вот это я и называю кучей кода :). Сравните с реализацией на руби:
persons.map(&:name).join ", "
Из типизированных таже scala может выразить это почти с краткостью руби.
2. Ситуации сплошь и рядом. Алгоритм опирающийся на хеш, как правило отличается от алгоритма, предполагающего, что данные лежат в коллекции. И стало быть методы доступа надо отличать. То есть у них как правило будет разное алгоритмическое окружение
Вы просто не сможете их перепутать — один требует два параметра, второй один. Вобще здесь спорить бесполезно, это вопрос скорее вкуса. Добавлю только, что алиасы методов в руби, когда метод может носить несколько названий, ИМХО очень правильная вещь. Можно до хрипоты спорить что length и size это семантический разные вещи, но то что можно вызывать любой просто удобно, не нужно лишний раз задумыватьсь, лезть в справку, или смотреть контекстные подсказки.
3. Он и показывает всё что вы сказали. Если никто по незнанию не перхватил исключение и не убил его трейс. И неважно открытая библиотека или закрытая. Хорошая также ещё допишет рекомендацию куда посмотреть и что предпринять. Spring к примеру.
Возможно в новых версиях ява так и есть. В моём случае сообщения, к сожалению, по чеховски кратки — такая то строка в таком-то файле, которого у меня нет :(
4. Опять же — быть может в вашем случае кто-то их перехватывает и к примеру прибивает вывод.
Опять же — ClassCast — и ни слова больше.
Сравните с реализацией на руби: persons.map(&:name).join ", "
Хороший код, это элегантный и понятный код. А не код сокращённый до упора.
Если я захочу писать такую конкатенацию одной строкой, я переопределю коллекцию и метод toString() и вообще везде буду делать return persons.toString(); Что ещё понятнее. Не велика проблема. :-)
А это и есть элегантный и понятный код любому кто знает руби на нормальном уровне.
Проблема действительно не велика, но в итоге получается что код на jave увеличивается в 2-4 раза. А читать код размером 30 строк или 100 это уже существенная разница.
Проблема действительно не велика, но в итоге получается что код на jave увеличивается в 2-4 раза. А читать код размером 30 строк или 100 это уже существенная разница.
Лучше приведите пример код на Java, который из массива выбирает уникальные значения, удаляет пустые и объединяет их по запятой
предположим такой код нам нужен при парсинге тегов
// я сам ни разу не писал проектов на java (кроме лабораторных) и мне интересно // как это будет выглядеть
предположим такой код нам нужен при парсинге тегов
// я сам ни разу не писал проектов на java (кроме лабораторных) и мне интересно // как это будет выглядеть
Можно до хрипоты спорить что length и size это семантический разные вещи, но то что можно вызывать любой просто удобно…
На первом месте стоит безопасность и лёгкое понимание. Следуя вашей логике на все случаи жизни можно придумать несколько операторов. ну что бы в хелп не лазить. Всякий раз делают что-то своё, зато слова одинаковые. :-)
Из за этого от перегрузки операторов кстати отказались. Ибо ХЗ что они делают в каждом конкретном случае. Надо рыскать по коду и искать.
ХЗ что делает любая функция, надо рыскать по коду и искать.
Повторю только что писал раньше: Руби это простота и красота результирующего кода за счёт некоторого усложнения языка, в то время как ява — многословность и как следствие усложнённость из-за невыразительности самого языка.
В общем, каждый выбирает по себе. Только рекомендую хорошо ознакомиться с альтернативами прежде чем выбирать. К вам это не относиться, но меня смешат знакомые java программисты, которые кроме явы видели максимум C++ (и самое интересное — не хотят ничего больше смотреть), но с остервенением доказывают что это лучшие из возможного.
Повторю только что писал раньше: Руби это простота и красота результирующего кода за счёт некоторого усложнения языка, в то время как ява — многословность и как следствие усложнённость из-за невыразительности самого языка.
В общем, каждый выбирает по себе. Только рекомендую хорошо ознакомиться с альтернативами прежде чем выбирать. К вам это не относиться, но меня смешат знакомые java программисты, которые кроме явы видели максимум C++ (и самое интересное — не хотят ничего больше смотреть), но с остервенением доказывают что это лучшие из возможного.
Вы уж извините, но на Java так никто не пишет(нетипизированные коллекции, конкатенация строк), я уж про синтаксические/стиллистические ошибки молчу. Steamus всё правильно написал. Так что лучше уж пишите ваш «понятный и идиоматичный» Ruby-код, думаю от роста его количества популярность Ruby будет больше, чем от таких «сравнений»)
=begin
Collectionpersons = ...; // заполняем коллекцию
for( Person person: persons ) {
System.out.println( person.getName() + "," );
}
// ** Убрать последнюю запятую если не нужна
=end
Это не тот код. Это вывод на экран, а руби код объединял массив в строку. Здесь нужен как минимум ещё код для конструирования строки.
valodzka конечно прав что руби элегантней Java, но суть вовсе не в количестве строк кода, а совсем другом.
Разница идеологическая, эти языки ощущаются совсем по разному. Когда ты пишешь на Ruby — ты в своём мире, где ты делаешь то, что ты хочешь. Ты свободен. На Java — ты в мире правил и ограничений, которые для тебя создали другие. Не ты решаешь что ты можешь/не можешь, а Java committees.
Конечно если ты необразованный индус, или Вася Пупкин 13-ти лет, то правила Java тебе только на пользу, они не дают тебе прострелить себе ногу. Но если ты всеръез воспринимаешь программирование как своё основное занятие и увлечение, а главное — творчество, то ты никогда не станешь себя ограничивать языком.
Сложно представить себе художника который решит выбрать холст на котором можно рисовать только тремя хорошо сочетающимися красками, или скульптора который выберет глину засыхающую только в прямоугольных формах. Творческие люди должны иметь максимальную свободу самореализации, что порой выливается в грандиозные провалы, но это также рождает и шедевры, которых раньше никто не мог себе вообразить.
P.S. Возможно это не совсем ответ на ваше сообщение, просто наболело. Если так — извиняюсь.
P.P.S. Слово Ruby в тексте можно заменить именем практически любого другого динамического языка.
Collectionpersons = ...; // заполняем коллекцию
for( Person person: persons ) {
System.out.println( person.getName() + "," );
}
// ** Убрать последнюю запятую если не нужна
=end
Это не тот код. Это вывод на экран, а руби код объединял массив в строку. Здесь нужен как минимум ещё код для конструирования строки.
valodzka конечно прав что руби элегантней Java, но суть вовсе не в количестве строк кода, а совсем другом.
Разница идеологическая, эти языки ощущаются совсем по разному. Когда ты пишешь на Ruby — ты в своём мире, где ты делаешь то, что ты хочешь. Ты свободен. На Java — ты в мире правил и ограничений, которые для тебя создали другие. Не ты решаешь что ты можешь/не можешь, а Java committees.
Конечно если ты необразованный индус, или Вася Пупкин 13-ти лет, то правила Java тебе только на пользу, они не дают тебе прострелить себе ногу. Но если ты всеръез воспринимаешь программирование как своё основное занятие и увлечение, а главное — творчество, то ты никогда не станешь себя ограничивать языком.
Сложно представить себе художника который решит выбрать холст на котором можно рисовать только тремя хорошо сочетающимися красками, или скульптора который выберет глину засыхающую только в прямоугольных формах. Творческие люди должны иметь максимальную свободу самореализации, что порой выливается в грандиозные провалы, но это также рождает и шедевры, которых раньше никто не мог себе вообразить.
P.S. Возможно это не совсем ответ на ваше сообщение, просто наболело. Если так — извиняюсь.
P.P.S. Слово Ruby в тексте можно заменить именем практически любого другого динамического языка.
Это не тот код. Это вывод на экран, а руби код объединял массив в строку. Здесь нужен как минимум ещё код для конструирования строки.
Используя Google Collections:
public class PersonList {
private List<Person> persons = ...
...
public String toString() {
return Join.join(", ", persons);
}
}Возвращает строку — теперь подойдёт?
… много громких и красивых слов...
Разработчик не художник а ремесленник, хватит уже «о высоком». Всё вышесказанное не имеет отношения к реальной разработке. Java — индустрия, а Ruby как был гетто, так им и остаётся.
Судя по вашим словам: такие компании как Google ограничивают себя использованием Java, только потому что там необразованные 13-летние индусы Васи Пупкины, которые не воспринимают программирование как своё основное занятие?
Самый популярный динамический язык(JavaScript) со следующей версии будет поддерживать опциональное статическое типизирование, второй(PHP) — отчасти тоже.
Всё вышесказанное мной _имеет_ отношение к разработке, просто видимо не ко всей.
Такие компании как Google, помоему во всю молотят на питоне. Использование Java вполне оправдано как стандарта, но я больше чем уверен, что большая часть инновации исходит из среды питонистов.
Я конечно рискую оказаться закопанным в грязь, но на мой взгляд в Google по большей части всё-таки работают те кто воспринимают программирование как просто работу, пускай и интересную. На такой вывод меня наталкивает чтение блогов множества людей работающих в Google.
Конечно есть и другие, выдающиеся личности, работающие в Google, но они там я думаю просто рубят немеренно денег, и поэтому просто поступают разумно используя ситуацию для свой выгоды.
А по поводу статического типизирования, каким образом это вообще относится к динамизму языка?
Такие компании как Google, помоему во всю молотят на питоне. Использование Java вполне оправдано как стандарта, но я больше чем уверен, что большая часть инновации исходит из среды питонистов.
Я конечно рискую оказаться закопанным в грязь, но на мой взгляд в Google по большей части всё-таки работают те кто воспринимают программирование как просто работу, пускай и интересную. На такой вывод меня наталкивает чтение блогов множества людей работающих в Google.
Конечно есть и другие, выдающиеся личности, работающие в Google, но они там я думаю просто рубят немеренно денег, и поэтому просто поступают разумно используя ситуацию для свой выгоды.
А по поводу статического типизирования, каким образом это вообще относится к динамизму языка?
Такие компании как Google, помоему во всю молотят на питоне.
Что в Гугле, что в Яндексе на питоне простые (саб)сервисы + скрипты. Инновации типа GWT, Android, Guice — это всё Java.
… гугловцы — скушные ребята...
Можно поинтересоваться, какие инновации преподнесли нам рубисты с питонистами? В чём заключается их творчество.
А по поводу статического типизирования, каким образом это вообще относится к динамизму языка?
Ну из ваших слов можно было понять, что динамические языки не ровня статическим. В то время выходит, что самые популярные из них теперь начинают перенимать идеи как раз у статических.
К примеру на Scala я могу делать повторять Ruby код с примерно таким же количеством key strokes, только это будет type-safe и работать в 10 раз быстрее. Но ведь это не повод переходить с Ruby на Scala, хоть Twitter так и делает со своим бекендом. Дело далеко не в языке — он лишь средство для выражения мыслей.
А вот если аккуратно проследить хронологию сообщений, то можно заметить, что вначале образец кода написал я, а уж затем valodzka. То есть ему захотелось накопить имена в переменную. Ну чтож, не велика проблема. Постановка же задачи выглядела так:
Вот я и получил их на экране. Не домысливая, что надо получить их в переменную. Что, как уже было показано, также совсем несложно.
Насчёт того, что творческие люди должны иметь максимальную свободу самореализации, я конечно согласен. Но на современном этапе развития цивилизации, беда скорее в том, что многие программисты являются излишне творческими. Программирование, это техническая индустрия и её по возможности хотят свести к ремеслу. Полностью это не получится, но насколько возможно это стараются сделать. И причина не в том, что бы обделить программистов творчеством, причина в том, что от работы программ зависят очень и очень много промышленных отраслей. Предполагать, что эти программы будут поддерживать исключительно гении, уже давно стало непозволительной роскошью.
И да, бог с ними с необразованным индусом, или Васей Пупкиным 13-ти лет. Но вы сами, в состоянии усталости и под стрессом можете запутаться в своём коротком рубленом коде, если будете писать его как гений-художник. Такие подходы уже давно себя изжили. Жизнь оказалась более прагматичной. :-)
Давайте пример — есть коллекция объектов типа Person, у них есть name. Частая практическая задача: получить их список имён через запятую — как это сделать коротко и просто в Java?
Вот я и получил их на экране. Не домысливая, что надо получить их в переменную. Что, как уже было показано, также совсем несложно.
Насчёт того, что творческие люди должны иметь максимальную свободу самореализации, я конечно согласен. Но на современном этапе развития цивилизации, беда скорее в том, что многие программисты являются излишне творческими. Программирование, это техническая индустрия и её по возможности хотят свести к ремеслу. Полностью это не получится, но насколько возможно это стараются сделать. И причина не в том, что бы обделить программистов творчеством, причина в том, что от работы программ зависят очень и очень много промышленных отраслей. Предполагать, что эти программы будут поддерживать исключительно гении, уже давно стало непозволительной роскошью.
И да, бог с ними с необразованным индусом, или Васей Пупкиным 13-ти лет. Но вы сами, в состоянии усталости и под стрессом можете запутаться в своём коротком рубленом коде, если будете писать его как гений-художник. Такие подходы уже давно себя изжили. Жизнь оказалась более прагматичной. :-)
Понимаете, вождение Таврии имеет ряд специфических особенностей, присущих настоящим водителям, и многие, с застарелым бмвэшным стилем этого часто не понимают…
да ладно, где вы нашли нападки?
речь имхо шла о том, что в рельсах многон принято делать по-другому, и все.
речь имхо шла о том, что в рельсах многон принято делать по-другому, и все.
Интересно по поводу пункта 1 и 2. Скажем, чтобы вывести вот эту страничку, нужен десяток инстанс-переменных: топик, дерево комментов, работа, популярные блоги и т. д. Соответственно, методов у моделей (их тут явно много должно быть) дергается порядочное количество.
Я так полагаю, что автор предлагает в таких случаях использовать паттерн Presenter?
5. @model.find*, собственно говоря, не существует. Правильнее писать Model.find. Если в данном случае использовать named_scope (вкупе с пунктами 1 и 2),- получится вполне себе рабочая схема (и кэшировать такие фрагменты проще)
ЗЫ. Рекомендации автора направлены на то, чтобы превратить push-модель шаблонов в pull-модель. То есть данные не передаются вьюхе, а вытягиваются ею самостоятельно (в случае Presenter, они фактически тянутся этим самым презентером).
Я так полагаю, что автор предлагает в таких случаях использовать паттерн Presenter?
5. @model.find*, собственно говоря, не существует. Правильнее писать Model.find. Если в данном случае использовать named_scope (вкупе с пунктами 1 и 2),- получится вполне себе рабочая схема (и кэшировать такие фрагменты проще)
ЗЫ. Рекомендации автора направлены на то, чтобы превратить push-модель шаблонов в pull-модель. То есть данные не передаются вьюхе, а вытягиваются ею самостоятельно (в случае Presenter, они фактически тянутся этим самым презентером).
«Все имена классов и переменных должны быть понятны даже новому разработчику. Избегайте длинных имен и аббревиатур.»
Тут явное противоречие. Аббревиатуры используются для того, чтобы сократить длинные имена. Короткие имена становится трудно читать, потому что обычно их сокращают до неузнаваемости от оригинального слова, получается они не понятны. Может быть тут идет речь о каких-то супер длинных именах?
«Архитектурные решения должны быть наиболее простыми. Не нужно закладывать в приложение зачатки будущей функциональности.»
Есть два типа простоты. Простота в написании здесь и сейчас этого метода. И простота его поддержки и возможность расширения функционала. Если не думать о возможных требованиях к коду в будущем, получается простота по первому типу и сложность по второму. А все мы знаем, что отлаживание и существующего кода происходит гораздо дольше, чем написание нового. В итоге сложность поддержки скажется гораздо существеннее на времени разработки, если делать все как бог на душу положит. Ну конечно стоит минимизировать сложность первого типа, где возможно но и не забывать про возможную расширяемость и мзменения требований.
Тут явное противоречие. Аббревиатуры используются для того, чтобы сократить длинные имена. Короткие имена становится трудно читать, потому что обычно их сокращают до неузнаваемости от оригинального слова, получается они не понятны. Может быть тут идет речь о каких-то супер длинных именах?
«Архитектурные решения должны быть наиболее простыми. Не нужно закладывать в приложение зачатки будущей функциональности.»
Есть два типа простоты. Простота в написании здесь и сейчас этого метода. И простота его поддержки и возможность расширения функционала. Если не думать о возможных требованиях к коду в будущем, получается простота по первому типу и сложность по второму. А все мы знаем, что отлаживание и существующего кода происходит гораздо дольше, чем написание нового. В итоге сложность поддержки скажется гораздо существеннее на времени разработки, если делать все как бог на душу положит. Ну конечно стоит минимизировать сложность первого типа, где возможно но и не забывать про возможную расширяемость и мзменения требований.
>> Код каждого установленного плагина предварительно изучается.
Я с ума сойду, пока буду разбираться в коде, например rspec и rspec_rails. В такой формулировке мне кажется это неправильным. Аргументируйте свою позицию пожалуйста.
А я бы подправил этот пункт следующим образом: если плагин генерирует код в основное приложение, то этот код должен быть изучен. Тут, правда, есть такой момент, что генерация слишком большого количества кода, с которым разработчик не знаком — само по себе плохо.
Я с ума сойду, пока буду разбираться в коде, например rspec и rspec_rails. В такой формулировке мне кажется это неправильным. Аргументируйте свою позицию пожалуйста.
А я бы подправил этот пункт следующим образом: если плагин генерирует код в основное приложение, то этот код должен быть изучен. Тут, правда, есть такой момент, что генерация слишком большого количества кода, с которым разработчик не знаком — само по себе плохо.
Ну вот rspec — неудачный пример. Он во-первых проверенный, а во-вторых в работе непосредственно приложения не участвует.
А вот какой-нибудь acts_as_* может выкинуть какую-нибудь подлянку. Я вот однажды наступил на изрядные грабли с acts_as_taggable.
А вот какой-нибудь acts_as_* может выкинуть какую-нибудь подлянку. Я вот однажды наступил на изрядные грабли с acts_as_taggable.
Поподробнее про грабли пожалуйста
Грабли очевидны после первого же взгляда на код find_tagged_with: не понимает named_scopes/файндеров, не поддерживает eager loading
да, на всякий случай: это был acts_as_taggable-2.0.2
если появилось что-то более приличное — срочно дайте знать :)
если появилось что-то более приличное — срочно дайте знать :)
acts_as_taggable_on_steroids?
agilewebdevelopment.com/plugins/acts_as_taggable_on_steroids
agilewebdevelopment.com/plugins/acts_as_taggable_on_steroids
Ну, вообще это нормально по ходу работы с плагином в нем разбираться. Что-то не работает — начинаем копать. А вот утверждать, что пока код от сих до сих не вызубришь и не поймешь, плагин ставить нельзя — это как-то очень жестоко и идеологически неправильно.
Я не понял, каким образом «предварительно изучать» превратилось в «вызубрить… ставить нельзя». В оригинале было так:
Every plugin installed has been code reviewed.
Most plugins in the Ruby on Rails community are at least good, if not great. However, the number of poorly designed plugins will increase. Always review the actual code of the plugin. In general, the simpler/smaller its code base is, the better. The more well-tested it is, the better. The easier its code is to understand, the better.
Do you understand how it works?
Do you understand its rough performance?
И этот совет кажется мне весьма резонным.
Every plugin installed has been code reviewed.
Most plugins in the Ruby on Rails community are at least good, if not great. However, the number of poorly designed plugins will increase. Always review the actual code of the plugin. In general, the simpler/smaller its code base is, the better. The more well-tested it is, the better. The easier its code is to understand, the better.
Do you understand how it works?
Do you understand its rough performance?
И этот совет кажется мне весьма резонным.
Да, отчасти все так. До тех пор пока не родятся 'next' ruby нидзя, которые изменят очередное представление обычных вещей.
Как показала практика даже таких простых сервисов, как danbooru, ROR — это бомба замедленного действия.
Почему? Интересует объективная конкретика: язык и фреймворк очень привлекательны, хочу использовать в реальных проектах.
Позвольте ответить несколько иносказательно — по следам сегодняшнего анекдота с Эха.
Звонит слушатель и спрашивает — Вот вы знаете у меня была машина — например отечественной марки — никаких проблем с ней не было — все что надо менял, заливал бензин и ездил.
А теперь вот купил например «Тойоту», делаю с ней все то же самое — и постоянные проблемы.
Вот так же и с технологиями, если вы сегодня используете какой-то простой инструмент, он вас в целом устраивает и вы к нему привыкли — подумайте прежде чем его менять и уж точно не делайте это на критически важном проекте. Любая технология более высокого уровня характерна тем, что работает только при правильном использовании, а если пытаться применять к ней практики, которые вы использовали раньше, то результат будет отрицательным, для кого-то даже «бомбой замедленного действия» — вот отсюда и разочарование.
Звонит слушатель и спрашивает — Вот вы знаете у меня была машина — например отечественной марки — никаких проблем с ней не было — все что надо менял, заливал бензин и ездил.
А теперь вот купил например «Тойоту», делаю с ней все то же самое — и постоянные проблемы.
Вот так же и с технологиями, если вы сегодня используете какой-то простой инструмент, он вас в целом устраивает и вы к нему привыкли — подумайте прежде чем его менять и уж точно не делайте это на критически важном проекте. Любая технология более высокого уровня характерна тем, что работает только при правильном использовании, а если пытаться применять к ней практики, которые вы использовали раньше, то результат будет отрицательным, для кого-то даже «бомбой замедленного действия» — вот отсюда и разочарование.
кстати именно поэтому это очень хороший пост — он о реальных практиках, жаль только что он столь сильно «завязан» не Rails — при некоторых пояснениях это вполне общие рекомендации
Простите, я спросил конкретно. Рассуждения о поведении сферического коня в вакууме хороши чтоб потрепать языком в пабе, но не здесь.
Не очень понимаю, что значит «простой инструмент». Возможно, инструмент простой в смысле KISS. Однако, я не нашёл существенных недостатков при сравнении с PHP/Symfony/Cake (PHP-опыт — шесть лет) — то есть, нет задачи, которую я не мог бы реализовать на ROR — но мог бы на PHP. При этом, по моему, не очень богатому опыту в ROR, на рельсах та же задача требует меньше времени, решается на порядок более комплексно и однородно, и требует меньше сил при поддержке и внесении модификаций.
Поэтому, ROR для меня привлекателен — и я спросил, что конкретно показала ваша практика. Мне хочется быть осведомлённым о повторных камнях. Какие конкретно подводные камни существуют?
Не очень понимаю, что значит «простой инструмент». Возможно, инструмент простой в смысле KISS. Однако, я не нашёл существенных недостатков при сравнении с PHP/Symfony/Cake (PHP-опыт — шесть лет) — то есть, нет задачи, которую я не мог бы реализовать на ROR — но мог бы на PHP. При этом, по моему, не очень богатому опыту в ROR, на рельсах та же задача требует меньше времени, решается на порядок более комплексно и однородно, и требует меньше сил при поддержке и внесении модификаций.
Поэтому, ROR для меня привлекателен — и я спросил, что конкретно показала ваша практика. Мне хочется быть осведомлённым о повторных камнях. Какие конкретно подводные камни существуют?
никогда не знаешь, где случится подлянка — в кривоватом монгреле, дырявых find-методах или вообще в каком-нибудь act_as_taggable плагине…
я, конечно, слегда утрирую, но тем не менее считаю, что рельсы своей зрелости не достигли.
я, конечно, слегда утрирую, но тем не менее считаю, что рельсы своей зрелости не достигли.
Когда они достинут той «зрелости» про которую вы говорите, то превратятся в полную скучищу, а все кто сейчас под них пишут уйдут куда-нибудь в Smalltalk, LISP, Erlang или ещё куда-нибудь.
Rails это live on the edge, для тех кто не боится ковыряться в чужом коде, фиксить баги в опен сорс проектах, делать свои плугины. Чтобы хорошо писать на рельсах нужно постоянно быть «в теме,» а не как в случае с другими развитыми технологиями — прочитал одну книжку, и пишешь три года по ней.
Кому-то это не подходит, для кого-то программинг это just a job, тогда рельсы не для них. Рельсы всё таки для тех кто дышит программингом. Остальным они не понравятся.
Rails это live on the edge, для тех кто не боится ковыряться в чужом коде, фиксить баги в опен сорс проектах, делать свои плугины. Чтобы хорошо писать на рельсах нужно постоянно быть «в теме,» а не как в случае с другими развитыми технологиями — прочитал одну книжку, и пишешь три года по ней.
Кому-то это не подходит, для кого-то программинг это just a job, тогда рельсы не для них. Рельсы всё таки для тех кто дышит программингом. Остальным они не понравятся.
Даже на *nix платформах Ruby более, чем в 10 раз медленнее, чем даже неродной для *nix C#.
Скэйлится ROR плохо. Тонны магии поначалу очаровывают, но потом ты понимаешь, что один шаг в сторону и чары развеиваются и перед глазами предстаёт суровая реальность. Приходится либо прогнуться под ROR, либо бороться со сложностями.
Мне лично не понятно, в чём преимущества ROR перед .Net 3.5 + ASP.Net MVC (даже при написании hello world).
Скэйлится ROR плохо. Тонны магии поначалу очаровывают, но потом ты понимаешь, что один шаг в сторону и чары развеиваются и перед глазами предстаёт суровая реальность. Приходится либо прогнуться под ROR, либо бороться со сложностями.
Мне лично не понятно, в чём преимущества ROR перед .Net 3.5 + ASP.Net MVC (даже при написании hello world).
Я сейчас делаю параллельно два проекта: один на ASP.Net MVC, а второй — начал на ROR. Оговорюсь, оба проекта будут малопосещаемыми — так что, скейлинг им не понадобится. Кроме того, они не связаны с вычислениями — так что, скорость тут тоже не играет роли. ASP.NET используется, так как нужна связь с 1C и потому заказчик поставил условие разрабатывать на C#.
Я увидел главное преимущество ROR: рельсы — однородная среда, содержащая решения большей части типовых задач, возникающих при разработке сайтов. Чего пока не скажешь об ASP.NET MVC.
Скажем, в ASP я не смог решить стандартными средствами следующие задачи:
— Доступ к данным через ORM (использую сторонний продукт — NHibernate; MVC в ASP это VC).
— Миграции.
— Простая работа с AJAX (конкретно — отправка файлов через AJAX).
— Работа с шаблонизаторами, кроме ASP (нужно писать свой плагин).
— Постраничный вывод.
— Загрузка и обновление тестовых данных в базе.
В ROR все эти задачи решились без особенных выкрутасов средствами, входившими в комплект — и описанными в документации, а не в гугле.
Любой инструмент хорош для своих задач. Мне обычно нужно сделать быстро, надёжно и изменяемо, а скорость выполнения стоит на десятом месте. Потому и изучаю ROR.
А можно подробнее насчёт скейлинга? И: что подразумевается под «шагом в сторону»? Видимо, при разработке на ROR, была какая-то конкретная проблема? Какая именно?
Я увидел главное преимущество ROR: рельсы — однородная среда, содержащая решения большей части типовых задач, возникающих при разработке сайтов. Чего пока не скажешь об ASP.NET MVC.
Скажем, в ASP я не смог решить стандартными средствами следующие задачи:
— Доступ к данным через ORM (использую сторонний продукт — NHibernate; MVC в ASP это VC).
— Миграции.
— Простая работа с AJAX (конкретно — отправка файлов через AJAX).
— Работа с шаблонизаторами, кроме ASP (нужно писать свой плагин).
— Постраничный вывод.
— Загрузка и обновление тестовых данных в базе.
В ROR все эти задачи решились без особенных выкрутасов средствами, входившими в комплект — и описанными в документации, а не в гугле.
Любой инструмент хорош для своих задач. Мне обычно нужно сделать быстро, надёжно и изменяемо, а скорость выполнения стоит на десятом месте. Потому и изучаю ROR.
А можно подробнее насчёт скейлинга? И: что подразумевается под «шагом в сторону»? Видимо, при разработке на ROR, была какая-то конкретная проблема? Какая именно?
>Я увидел главное преимущество ROR: рельсы — однородная среда, содержащая решения большей части типовых задач, возникающих при разработке сайтов
Если вы говорите такое об .Net/ASP.Net, Вам будет очень сложно…
>— Доступ к данным через ORM
Linq to SQL, Entity Framework
>— Миграции.
Linq to SQL
>— Простая работа с AJAX
ASP.net AJAX, jQuery
>— Работа с шаблонизаторами, кроме ASP
напишите подробнее, что требуется (и как этому поможет ROR)
>— Постраничный вывод.
Делается за несколько строк множеством способов. Например, weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx weblogs.asp.net/scottgu/archive/2006/03/22/Efficient-Data-Paging-and-Sorting-with-ASP.NET-2.0-and-SQL-2005.aspx weblogs.asp.net/scottgu/archive/2006/01/07/434787.aspx weblogs.asp.net/scottgu/archive/2006/01/01/434314.aspx
>— Загрузка и обновление тестовых данных в базе.
Linq to SQL
Если Вы не умеете пользоваться MSDN, входящим в комплект Вам будет сложнее писать программы.
Советую также прочитать весь блог weblogs.asp.net/scottgu за последние пару лет. Поможет.
Правда от нежелания разбираться в неизвестных технологиях то не спасёт всё равно.
Если вы говорите такое об .Net/ASP.Net, Вам будет очень сложно…
>— Доступ к данным через ORM
Linq to SQL, Entity Framework
>— Миграции.
Linq to SQL
>— Простая работа с AJAX
ASP.net AJAX, jQuery
>— Работа с шаблонизаторами, кроме ASP
напишите подробнее, что требуется (и как этому поможет ROR)
>— Постраничный вывод.
Делается за несколько строк множеством способов. Например, weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx weblogs.asp.net/scottgu/archive/2006/03/22/Efficient-Data-Paging-and-Sorting-with-ASP.NET-2.0-and-SQL-2005.aspx weblogs.asp.net/scottgu/archive/2006/01/07/434787.aspx weblogs.asp.net/scottgu/archive/2006/01/01/434314.aspx
>— Загрузка и обновление тестовых данных в базе.
Linq to SQL
Если Вы не умеете пользоваться MSDN, входящим в комплект Вам будет сложнее писать программы.
Советую также прочитать весь блог weblogs.asp.net/scottgu за последние пару лет. Поможет.
Правда от нежелания разбираться в неизвестных технологиях то не спасёт всё равно.
Цитирую: «В виде никогда не делаются вызовы Find». Для чего это? Вот например я использую некоторые хелперы, которые плодят такие вызовы, но в виде все красиво, один вызов хелпера и все.
Потому что это разрушает паттерн MVC. Потому что тестировать такие views очень сложно — нужно, вместо заполнения assigns на входе, лепить еще и фикстуры/моки. Ну и наконец, потому что размазывание логики по views приводит код к состоянию, в котором его очень сложно поддерживать и сопровождать. Особенно, если это не ваш код.
хех) вот где тусуются люди у которых в данный момент нет работы (:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перечень требований к коду Ruby on Rails приложения