Вводный учебник, написанный пользователем сети (чтобы скачать, войдите в систему).
Знакомство с языком Ruby, установкой Rails и простым примером. Очень полезно для новичков. Настоятельно рекомендуется!
Если вы занимаетесь разработкой j2ee как Java-программист, вы наверняка будете использовать множество фреймворков приложений. Ни один язык не является столь активным, как сообщество языков Java, и любая новая концепция программирования вскоре будет иметь соответствующие реализации с открытым исходным кодом в Интернете. В соответствии с наиболее часто используемой моделью разработки веб-сайтов MVC каждый уровень будет иметь множество платформ Struts и Tapestry, принадлежащих уровню контроллера (C), а платформа Velocity принадлежит уровню представления (V), который вы можете использовать. быть Hibernate, iBatis, OJB или любая из многих реализаций JDO с открытым исходным кодом, например JPOX. Но наличие слишком большого выбора – это не обязательно хорошо, и не каждый может принять правильную структуру, чтобы поступать правильно. Если вашей платформой разработки является .net, вы можете избежать этой ситуации. Обычно вам нужно только установить Visual Studio .net в качестве инструмента разработки, а затем установить MSDN для поиска информации. Для разработчиков программ это очень сложная ситуация. Лично мне очень нравится Java, будь то обучение или практика, она дает нам очень многое. Но почему я считаю, что «универсальные» решения, такие как .net, во многих случаях верны?
Как Java-программист, я считаю, что некоторые из наиболее очевидных проблем Java заключаются в том, что, во-первых, Java слишком сложна, а во-вторых, Java слишком ориентирована на программистов, а не на пользователя. По сравнению с C++ Java уже очень прост. Тот факт, что сейчас так много Java-программистов, иллюстрирует эту точку зрения. Но, как кто-то однажды сказал: «В Linux можно легко определить, кто хозяин», но в области Java это не так просто. Я часто обнаруживаю, что мои коллеги вокруг меня все еще допускают концептуальные ошибки очень низкого уровня. Они все еще могут заниматься разработкой j2ee в течение многих лет, даже если они не могут точно определить, что такое интерфейсы, абстрактные классы и сервлеты. Но почему Java называют сложной? Потому что для выполнения одной задачи требуется слишком много разных технологий? Итак, как можно гарантировать, что программисты, у которых нет четких представлений, сделают правильный выбор? И сколько из множества платформ предоставляют «универсальные» услуги? Недавно появившийся фреймворк Spring предоставляет больше всего сервисов среди многих фреймворков, но у него есть новая проблема: он по-прежнему слишком ориентирован на программистов, а не на пользователей. Почему ты так говоришь? Фреймворки изначально созданы для программистов, не так ли? Хотя Spring предоставляет множество вариантов выбора (но недостаточно, у него нет самого ORM), он не предоставляет простого способа его использования, поэтому мы можем только сказать, что он предназначен только для программистов. У большинства Java-фреймворков есть эта проблема, то есть кривая обучения относительно высока. Я думаю, что уровень обучения является ключом к тому, чтобы определить, предназначен ли фреймворк для программистов или пользователей. Я думаю, что это главным образом отражается на простоте использования фреймворка. Фактически, конечными пользователями фреймворка являются программисты. Причина, по которой мы используем термины «пользователи» и «программисты», заключается в том, что некоторые фреймворки для «программистов» сложны в использовании. они по-прежнему требуют, чтобы программисты собрали его самостоятельно. Платформа, ориентированная на пользователя, проще. Пользователям нужно только следовать инструкциям, чтобы ее использовать. Почему Ruby on Rails вызовет сенсацию в сообществе Java, я думаю, причина в том, что он предоставляет «универсальную», ориентированную на пользователя, простую и удобную в использовании среду, которой нет в среде Java. Почему Ruby on Rails может это сделать? Разве Java не может этого сделать? Дело в том, что многие проектировщики Java-фреймворков этого не делают. Возможно, их мышление ограничивалось тем, как использовать шаблоны для разработки хорошей инфраструктуры, и они не уделяли больше внимания простоте использования платформы. Любой, кто использовал Spring, знает, что его файл конфигурации xml будет постепенно расширяться, хотя для решения этой проблемы мы можем легко разбить его на более мелкие файлы конфигурации. Но при использовании файлов конфигурации XML следует общепринятой концепции программирования на Java: «Java — лучший язык программирования, XML — лучший язык для описания данных, а комбинация этих двух — наиболее совершенная. Если приложение не использует xml для его описания, то это нехорошее Java-приложение».
Однако именно в этом отношении Ruby on Railils отличается от многих Java-фреймворков и совершает прорыв в простоте использования фреймворка. Эта идея проходит через весь дизайн Rails: соглашение важнее конфигурации. Например, когда мы пишем веб-приложения на Java, мы обычно различаем соответствующие классы в соответствии с MVC. Лично мне нравится помещать класс Controller в веб-каталог, класс View в каталог представления, а класс модели в средний каталог домена. . Но у разных людей разные настройки и разные имена. Как сообщить платформе об этих разных каталогах. Единственное решение для платформы Java — сообщить ей эту информацию через файл конфигурации xml. Решение Rails следующее: я определяю структуру каталогов, и вам просто нужно поместить все в указанный мной каталог. Это важная причина, почему в рельсах очень мало файлов конфигурации (но их нет). Хотя идея очень проста, польза, которую она приносит, заключается в том, что эффективность разработки на Rails в 10 раз превышает эффективность разработки на Java (это утверждают поклонники рельсов, но я в это верю, и я уверен, что вы тоже это узнаете после прочтения этой статьи). ) . Так делает ли это одно только развитие рельсов быстрее, чем использование Java? Не совсем, потому что это также выигрывает от другой философии дизайна рельсов: меньше кода. Ни один язык не может похвастаться этим полностью благодаря языку проектирования Ruby. С помощью Ruby вы действительно можете написать множество функций на небольшом объеме языка, что просто невозможно на других языках. Чтобы освоить Rails, вы должны понимать Ruby. Кто-то однажды сказал: Zope (знаменитый веб-фреймворк Python) — это убийственное приложение Python, а Python — секретное оружие Zope. Я думаю, что это предложение наиболее подходит для описания отношений между рельсами и Ruby.
Расширять
