I have started a new web project and looked at RoR. Having done an app with Tapestry/Spring/Hibernate, I was sick of all the work one has to do to bring up a bunch of views in a browser and then persist results. I love RoR and Ruby for all the reasons mentioned in TFA. Note - I don't like the pluralisation default, but one can easily turn it off by setting the following in config/environment.rb:
# Include your application configuration below
ActiveRecord::Base.pluralize_table_names = false
There were two scalability concerns I had about RoR:
(1) Ruby is interpreted and 'slow' - however, the JRuby team (http://headius.blogspot.com/) is working on running Ruby within a JVM (currently interpreted, but they are starting on a compiler). When they get to 1.0, the compiler won't be as good as Sun's, but it will probably be "good enough"
(2) RoR uses the Active Record Pattern and Hibernate uses the Data Mapper Pattern (http://www.theserverside.com/tt/articles/article. tss?l=RailsHibernate). The Data Mapper Pattern is almost certainly more efficient when implemented well (as Hibernate does). The coolest thing about Hibernate is that it is much more efficient than I am without a big effort on the persistence side, and I am concerned that Active Record will not be nearly as good. However, what are the odds that someone (or some group of people) will work on implementing a persistence solution within Rails that uses the Data Mapper Pattern? Pretty good, I would say. Once again, it probably won't be as good as Gavin King's work, but it will be "good enough". And if someone else does not do it, maybe I will start the project.
Given the above and the speed with which one can develop in RoR, the choice was obvious, to go with Ruby and Rails.
Don't underestimate the effort involved in incorporating or in starting a business. It is complicated (else everyone would do it). The Korean guy with the produce market probably works 12-16 hour days, his wife might work in the shop, as might his kids. He has enough belief in himself (and knows enough relatives who also have done it) that he is willing to chance failure.
While it is complicated and a ton of work to start a business, it certainly is doable. It really helps to
(1) be naive and optimistic (if you knew all the problems that would come your way, you wouldn't even start, in all probability)
(2) be willing to give up all extra-curricular activity, except your family
(3) be driven by fear of failure (for financial reasons, ego, people dependent upon you, etc - preferably all of the above)
(4) be cynical - (if every suit who said he/she would OEM our product did so, I would be far richer than I am now)
My wife and I started a company, had kids and sold the company 10 years later. And now, we are going to do it again, in part because our previous experience was pretty damn fulfilling, especially for my ego.
The kind of person I would want to hire if I was doing kernel development, assuming that person is not totally psychotic. Buffer overflows are old hat, but an encrypted integer overflow in brk() sounds pretty creative to me.
Slashdot Mirror
I have started a new web project and looked at RoR. Having done an app with Tapestry/Spring/Hibernate, I was sick of all the work one has to do to bring up a bunch of views in a browser and then persist results. I love RoR and Ruby for all the reasons mentioned in TFA. Note - I don't like the pluralisation default, but one can easily turn it off by setting the following in config/environment.rb:
. tss?l=RailsHibernate). The Data Mapper Pattern is almost certainly more efficient when implemented well (as Hibernate does). The coolest thing about Hibernate is that it is much more efficient than I am without a big effort on the persistence side, and I am concerned that Active Record will not be nearly as good. However, what are the odds that someone (or some group of people) will work on implementing a persistence solution within Rails that uses the Data Mapper Pattern? Pretty good, I would say. Once again, it probably won't be as good as Gavin King's work, but it will be "good enough". And if someone else does not do it, maybe I will start the project.
# Include your application configuration below
ActiveRecord::Base.pluralize_table_names = false
There were two scalability concerns I had about RoR:
(1) Ruby is interpreted and 'slow' - however, the JRuby team (http://headius.blogspot.com/) is working on running Ruby within a JVM (currently interpreted, but they are starting on a compiler). When they get to 1.0, the compiler won't be as good as Sun's, but it will probably be "good enough"
(2) RoR uses the Active Record Pattern and Hibernate uses the Data Mapper Pattern (http://www.theserverside.com/tt/articles/article
Given the above and the speed with which one can develop in RoR, the choice was obvious, to go with Ruby and Rails.
Don't underestimate the effort involved in incorporating or in starting a business. It is complicated (else everyone would do it). The Korean guy with the produce market probably works 12-16 hour days, his wife might work in the shop, as might his kids. He has enough belief in himself (and knows enough relatives who also have done it) that he is willing to chance failure.
While it is complicated and a ton of work to start a business, it certainly is doable. It really helps to
(1) be naive and optimistic (if you knew all the problems that would come your way, you wouldn't even start, in all probability)
(2) be willing to give up all extra-curricular activity, except your family
(3) be driven by fear of failure (for financial reasons, ego, people dependent upon you, etc - preferably all of the above)
(4) be cynical - (if every suit who said he/she would OEM our product did so, I would be far richer than I am now)
My wife and I started a company, had kids and sold the company 10 years later. And now, we are going to do it again, in part because our previous experience was pretty damn fulfilling, especially for my ego.
The kind of person I would want to hire if I was doing kernel development, assuming that person is not totally psychotic. Buffer overflows are old hat, but an encrypted integer overflow in brk() sounds pretty creative to me.