Comparison between rails development and Java programming

Ruby on Rails development is essentially different from Java development. In Crossing boundariesIn the last phase of the series, Bruce Tate will outline the main differences found when developing a complex and scalable Web site from scratch using rails.

Rails developers often regard Java developers as boring and lazy. Java fans often think that Ruby on Rails is just a toy and cannot be used for any serious software development. As a consultant who has extensive experience with both technologies, I think the real situation is between these two points of view. As the series of articles that span borders are coming to an end, I plan to compare them again. This article does not look at a special technique or language, but mainly introduces the project I am currently working on and compares it with the Java project I previously worked on. In addition, I suggest you read the previous articles in the "crossing borders" series to learn more about related topics. This direct description allows you to weigh the pros and cons between the two, and may benefit you from using rails in the development of the database web application green-field.

Business problems

About this series In a series of articles that span borders, the author Bruce Tate put forward this idea that today's Java programmers can better arm themselves by learning other methods and languages. The programming prospects have changed since Java technology became the best choice for all development projects. Other frameworks affect the construction of Java frameworks. Concepts from other linguistics can also affect Java programming. The Python (or Ruby, smalltalk, and other languages) code you write can change the Java code writing method. This series introduces completely different programming concepts and technologies from Java development, but these concepts and technologies can also be directly applied to Java development. In some cases, these technologies need to be integrated to take advantage of them. In other cases, the concept can be applied directly. Specific tools are not important. What is important is that other languages and frameworks can affect developers, frameworks, and even basic methods in the Java Community.

Neither the Ruby on Rails framework nor any Java framework can solve all problems. To increase the chances of success, you need to examine your business problems, understand the assumptions around you, and understand your team. Only in this way can we select the correct language for development.

Last year, arvato Systems hired me to lead a team to build changingthepresent.org, a new platform for organizing non-profit groups and donors. Like many Internet companies, we show customers what they can buy. Different from other companies, these products refer to opportunities. For example, a cancer researcher charges $50 for an hour's service and $30 for helping blind people, or you are charged $20 a month to protect an acre of rain forest. We are faced with two major challenges: a tight schedule and long-term complexity.

Development starts in May and requires that a site be established before May so as to have the opportunity to catch up with the traffic peak during the Christmas period. (In the end, we have exceeded the deadline of February two weeks .) In other development languages, Java-based solutions may take 6 to 18 months to complete this task. Therefore, productivity is an important consideration, which is contrary to the Java deployment philosophy.

By examining competitors and projects, we learned that we hope to bring millions of clicks of traffic to the site every day. We need to have hundreds of thousands of successful clicks every day, so scalability is also a consideration. This is consistent with the Java deployment philosophy.

Finally, we learned that the initial site release is just the beginning. We have only achieved 3% of the overall plan. Therefore, the technology we selected needs to be adjusted based on complexity and load. I think Ruby is easier to adjust in terms of complexity because it provides support for more advanced languages and features (such as open classes, and a rails framework with fewer Configuration Requirements and simpler and integrated programming models.

Although we are faced with time and scalability challenges, we also have some other advantages. We have a completely blank Candidate List: You can select any technology or team you want. Project, training, and all technologies can be defined. We are free to make choices.

Java is an excellent general language. It is always applied to new technical fields, such as embedded systems and mobile devices. The Java language is also outstanding in the integration of a wide range of concerns. It is highly performing and popular and well supported by the platform. However, as you have learned in this series, Java is not the best choice for green-field development for Web applications supported by databases.

In contrast, the Ruby on Rails framework is new. Not many people use rails to develop high-traffic websites, and there is almost no experience in using rails for many years. However, it is still a framework for developing Web applications supported by highly productive databases. Finally, despite our lack of experience in developing long-term projects for rails and lack of extensive deployment concerns, the Compact schedule drove us to choose Ruby on Rails.

After making this decision, we found it very easy to recruit project talents. We also found that early productivity advantages were significant-or even better than expected. We have encountered some early stability problems, so we have strengthened our testing efforts. Since then, the stability has been greatly improved.

Principle

Each Framework designer uses a set of assumptions to construct the rewrite principle of the framework. Learning to abide by the constraints of this principle can make you program happily, and challenging these constraints will make your programming frustrated. The rails framework and Java framework have many different principles.

Rails is an integrated framework that uses the dynamic nature of Ruby language. Rails developers emphasize the framework's productivity characteristics rather than the tool features, and often make the Web architecture very simple. You have learned this in the previous articles in this series. Java designers usually have to combine the development environment in blocks and select the persistence, web, and Integration Layers independently. They usually rely heavily on tools to simplify core tasks. Web architecture design tends to be more complex.

Full integration

The Java framework often solves a small problem (such as persistence or viewing organizations), while rails is an integrated environment. The advantage of rails developers is that they do not have to solve the problem of integration with many different frameworks. Most hibernate developers fall into the trap of closing the connection with the Java Web framework too early. The rails view framework is built from scratch to integrate with activerecord (rails persistence framework ). You will also find similar experiences when examining the rails framework for Web Services, configurations, and ins. Java programming supports different frameworks and uses different integration policies for all these frameworks.

The advantage of Java developers is selection. If you need to build a framework from scratch, you may need to consider using SQL-based solutions for database integration (such as ibatis or one of the JDBC-based packaging frameworks in Java programming ). In turn, if you want to use an old mode for programming, you may need to use the object link ing framework (such as Hibernate ). In contrast, if you use rails, you have a primary choice: activerecord. This means that the Java framework provides more options and sometimes provides better integrated development project solutions. But because we want to develop a green-field project, it is not a problem to choose.

A Dynamic Language

The next major part of rails principles is the dynamic programming language. Java tools can often effectively use the additional information provided by the Java type model. Tools can identify errors and effectively refactor code. Rails also effectively utilizes the advantages of programming languages. Ruby is an ideal language for building a domain-specific language (DSL. Rails uses DSL in a centralized manner to complete all the work related to specified custom components (such as status machines or images that can be uploaded) from building model objects. Dynamic languages are often more concise, so rails projects are much more concise than Java projects, allowing users to express code and configuration more concisely. In the changingthepresent.org project, we found that top technical programmers can achieve higher productivity, but we do need to recruit more experienced developers. I am very satisfied with this compromise.

Traditional Java programmers have a close devotion to IDE, and there are good reasons for this phenomenon. IDE provides syntax integrity check, minor bug fixes, and incremental compilation for faster coding, compilation, deployment, and testing cycles. Over the past few years, the development environment has begun to better utilize the information provided by the compilation loop and static type. IDE now edits the abstract syntax tree (AST) instead of (or simultaneously) editing the text representation of the Code. This policy allows the use of powerful code refactoring tools, and it is much more difficult to implement this function using the same method of static type language.

Static types can indeed better use tools, but they also have disadvantages. A compiler is usually required to forcibly use static types, and the compilation steps will inevitably reduce productivity. With rails, I can change a line of code and reload the browser to see the change result immediately. Compared with Java developers, most Ruby developers only use a good editor. Textmate is the most popular Ruby on Rails editor. It provides syntax highlighting, code integrity check, and good template support for frequently used structures. However, when you find that you can put all simple ruby-based scripts (used as the basic rails Toolkit) into the editor, you will be even more overjoyed. Unlike a pure debugger, I can use a breakpoint script to stop a specific application and enter a Ruby interpreter, I can call a method, check the value of a variable, and even modify the code between the resume execution.

Simple Architecture

The traditional web-side Java architecture includes a layer for domain objects and data access objects, a service-level API appearance layer, a controller layer, and a view layer. This architecture is slightly more complex than the typical "Model-View-controller" Architecture (which was first created using the Smalltalk language. In contrast, Ruby on Rails includes a model layer, a controller layer, and a view layer that uses the activerecord design pattern. We like the easy-to-obtain rails method. It is more concise and brings more complexity and less chance of errors.

Convention priority principle

Java frameworks are generally free to use XML configurations, while rails mainly uses conventions to avoid possible configurations. When a programmer must specify the configuration location, rails usually relies on Ruby (often in DSL form) to provide configuration. For green-field development, I found that it makes sense to prioritize configuration. This policy saves us a lot of lines of code, which simplifies the code that must be written. It is estimated that the configuration we need is only one tenth specified in traditional Java applications. We sometimes lose some flexibility, but this is not enough to offset the savings caused by using this policy.

All in all, the principle of the rails framework is suitable for solving problems in the changingthepresent.org project. The various integrated tools allow me to use the framework to implement more functions without having to integrate too much on my own. The "conventional priority principle" saves me time to configure the site. Dynamic Language provides more capabilities and flexibility for experienced developers, and allows them to use less code to express more powerful ideas. This framework is suitable for our team's abilities and business problems to be solved.

Durability

The most popular persistence framework of Java and Ruby can better clarify the difference between Java and Ruby experience than any other features. Java developers usually use hibernate, it is an object-link ing framework. With hibernate, you can obtain existing models and patterns and use annotations or XML to express the ing between them. Hibernate class is a simple traditional Java object (pojo). Each of its objects is derived from a common base class. Most configurations are explicit, using annotations, XML, or a combination of the two.

Activerecord is a packaging framework, that is, each class is an existing class package. Activerecord automatically adds features to the model object based on the content of the associated table (such as an attribute of each column in the table. All classes are inherited from a general base class. Activerecord uses common conventions to infer configurations. For example:

• Activerecord uses the complex form of the class name to publish the table name.
• The primary key name isid.
• The list is sortedpositionField.

Object relationship ing is the best solution when the legacy mode is used (the object model may not be taken into account during definition. However, when you can explicitly design the database schema for your application, you usually do not need to map the framework. We regard activerecord as a huge advantage. We can include relational databases and transfer them to SQL when necessary and exit when appropriate.

Migration

Rails migration allows us to use code to represent the differences between two versions of the pattern and the data they contain. Each migration is named and numbered. Any version can be restored at any time. Migration has the following advantages:

• When an error code is generated, it can be restored to an old version.
• It is easier for us to use code instead of SQL expressions.
• It is independent from the database to the maximum extent.

However, there are some restrictions on migration. If two developers create a migration at the same time, the number will be messy, so we must manually handle it. We minimize these issues through effective communication: a notification is sent when a team member builds a new model that requires migration. However, this model depends on the small number of developers in the team or the Migration progress is slow.

Activerecord has other restrictions, some of which are intentionally made. Rails creators believe that the constraints and composition of databases should be classified into applications rather than databases, which brings some side effects. Activerecord does not use a view well: the Build Process (clone mode, copy test data, and run the test) cannot be copied correctly. Activerecord may also be faulty in some cases where reference integrity constraints are used, because some types of associations may be connected to multiple database tables. Loading across complex models is complex. SQL is usually used when multiple rows are connected. Inheritance is also restricted: I was forced to use activerecordSingle Table inheritanceIng policy, which is not always the best choice.

All persistence policies are full of compromises. I think activerecord achieves a valid set of compromises, and often chooses simplicity. All in all, activerecord and migration are our active drives. We can quickly build a solution, and we have enough SQL access to improve system performance as needed. However, when activerecord does not always respond to challenges, it is best to apply rails to projects that use the old mode. Some alternative persistence models are emerging, including rbatis, a port of the ibatis Java framework. It is too early to discuss the effectiveness of rbatis.

Conclusion

For my team and projects, Ruby on Rails has proved quite effective. I still don't know the final scale of this project, because the system was running for three months at the time of writing this article. Now, we only start to increase the traffic. However, we are very familiar with productivity. I know that the team budget is much lower than that of competing companies (these companies often use Java solutions. I am also confident in our productivity.

PassCrossing boundariesSeries, I will introduce you to languages and solutions beyond the Java field. But programmers are technical personnel after all. A toolkit for each brilliant technician should contain a wide set of tools suitable for each solution. In addition to tools, the ideas introduced in this series also show you some other ideas. Currently, some framework designers even apply the technologies in Seaside, rails, and even JavaScript to Java frameworks. Find the opportunity to carry out the same application and continue "Crossing the border ".

About the author

Bruce Tate is a father, a mountain cyclist, and a kayak who lives in Austin, Texas. He is the author of three of the best-selling Java books, including those who won the jolt AwardBetter, faster, lighter Java. He recently launchedFrom Java to RubyAndRails: Up and running. He worked at IBM for 13 years and then founded rapidred consultants, where he specializes in ruby-based lightweight development strategies and architectures and the Ruby on Rails framework. He is now the CTO of wellgood LLC, which is committed to opening up markets for non-profit organizations and welfare organizations.