Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s Up With All These Changes in Rails?

yehudakatz.com

Post reply on HN
Print view View original

101–110 of 115 posts

Re: What’s Up With All These Changes in Rails?

#101

Post by rapind »

jamesbritt wrote: post #82
cies wrote: post #67

Earlier quoted context omitted.

ORM is decoupled in rails to my knowledge... there is a default to AR which is easy to overwrite with your ORM of choice (which often provides an ActiveModel interface and further rails integration by installing one extra gem). tl;dr: providing sane defaults != strong coupling

OK, thanks, my mistake. Not coupled. But still, there is a strong presumption that your app will use a database and wants a database.yml. The few times I've wanted to just start a Rails app with simple Erb, with models representing data concepts (but not necessarily SQL anything), and evolve out to using a database (if and when needed), have been frustrating. It's something that has been easy to do in some other fram…

Yeah you can think of rails as requiring a database. You can pretty easily substitute whatever you want at the database level (sqlite3, mysql, postgresql, mongodb, even redis!), but it's the convention that you'll need to store and retrieve data in your webapp. If you don't need to do this (edge case for most of us), then try a different framework like sinatra that isn't accompanied by all the database bloat.

If you're planning on using a DB eventually but don't want to deal with migrations etc. for now, then start with a NoSQL DB like MongoDB (you don't even need to describe your fields, it can be completely dynamic). You can always sub in an RDBMS later on if your design calls for it.

Re: What’s Up With All These Changes in Rails?

#102

Post by rapind »

Jd wrote: post #22

There's a deeper problem that Yehuda isn't hitting and that is that there is an inverse correlation between being cool and cutting edge and being consumer friendly. Rails is, and really has always been, a framework which changes very quickly. Although virtually all of these changes are for the better either in some abstract feels-better sense or in a tangible practical sense, each of these changes imposes a cost on o…

1) You don't have to stay up to date with the latest. Pick a version and hunker down. I.e. 2.3.11. Forget about Rails3 for a year or 2 if you like (not me, I happen to really like rails 3). This is what I'd do if I was a part-time rails dev.

2) This couldn't be more incorrect. I'm not sure where you got this impression, but I have several apps in production I haven't touch in over a year. I don't even think I've bounced any services like apache or passenger on that box in over a year. I didn't do anything fancy to make this possible. Are you constantly upgrading your apps when new versions come out? Would you do that with a production EJB app?

3) This is true, but isn't specific to Rails or Ruby developers.

One thing I'll say is that Rails 3 definitely has a higher learning curve than 1 or 2 did. I think that's just the framework growing up though. It's a pretty complicated area of development if you want to build a decent sized app. If you're building something really simple and small, rails 3 might be overkill, at least for the time being until it settles down a bit.

Re: What’s Up With All These Changes in Rails?

#103

Post by sunir »

lifo wrote: post #72
jamesbritt wrote: post #59

Earlier quoted context omitted.

Best of all worlds would have been to drop AR altogether and promote a migration to Sequel for the official Rails O/RM. ;-) Indeed. Or decouple the ORM entirely, though that likely removes a key aspect of what Rails is about. It is, however, what makes Ramaze so appealing. No coupling to any ORM, but there is a community inclination to use Sequel (so you can learn from example and there are people to answer questions…

You seem to know very little about Rails 3. But if you think ramaze has a "community", I guess I can understand why.

Teach, don't snark. Snarking only teaches that the teacher is a snark.

Re: What’s Up With All These Changes in Rails?

#104

Post by lapusta »

jshen wrote: post #36
SeanDav wrote: post #16

Earlier quoted context omitted.

Agree that Yehuda is calm and makes good points - However the main point of the original article still remains intact - Rails is very hard for the beginner to learn, much harder than before.

"Rails is very hard for the beginner to learn" compared to what? Have you tried to learn Spring MVC? No way rails is harder to learn than that. Are you comparing it to no-framework php files? Forgive me, but I fail to see how the main point of the original article is even valid.

Or even EJB2 & JSF on WebSphere :)

Re: What’s Up With All These Changes in Rails?

#105

Post by ssmoot »

aaronblohowiak wrote: post #88
ssmoot wrote: post #49

Earlier quoted context omitted.

A 10% performance penalty to get down and dirty with your Domain Model and go all HSQL isn't exactly a big price to pay. Take a peek at Paul's benchmark. Iterate and instantiated 100K empty objects in 10s. That's crazy. You're talking about something that would probably take 1ms in c#. You're talking about a performance deficit four orders of magnitude large. Regardless, I think you've entirely missed the point. The…

The mono C# compiler should pre-evaluate the loop and just set x to the computed value. You'd have to look at the bytecode to verify, but i would be shocked if mono didn't do that. Still, it should take the blink of an eye, not a chin-scratch.

I get that it could, is there a reason you think it actually does?

Either way, nice observation. Interesting.

Re: What’s Up With All These Changes in Rails?

#106

Post by ssmoot »

wedesoft wrote: post #100
ssmoot wrote: post #49

Earlier quoted context omitted.

A 10% performance penalty to get down and dirty with your Domain Model and go all HSQL isn't exactly a big price to pay. Take a peek at Paul's benchmark. Iterate and instantiated 100K empty objects in 10s. That's crazy. You're talking about something that would probably take 1ms in c#. You're talking about a performance deficit four orders of magnitude large. Regardless, I think you've entirely missed the point. The…

The Ruby program takes more time because it is not optimised and it also checks for numeric overflow. The following Ruby program puts (1 .. 21).inject :* will output "51090942171709440000". And puts (1 .. 21).inject(:*).class will output "Bignum" because Ruby switches to big numbers when its integer representation is exceeded.

You make a valid point, but I think it's missing the forest. The example I posted actually results in a Fixnum. It's addition, not multiplication.

Simple math operations are an admittedly terrible way to demonstrate the point I was trying to make (method dispatch and object instantiation overhead). Dismiss it, accept it, or dig deeper verify it. :-)

Re: What’s Up With All These Changes in Rails?

#107

Post by 5l »

trustfundbaby wrote: post #57
ayb wrote: post #44

Earlier quoted context omitted.

>> Something as major as the asset pipelining feature (where you move assets out of the public folder and into the app folder), for example, seems big enough that it should be a 3.2 release not the next release after an already major change in 3.0. What's the difference between putting it in 3.1 vs. 3.2? Is the 3.2 version number somehow more substantial than 3.1? Also there have been quite a few releases after 3.0 -…

What's the difference between putting it in 3.1 vs. 3.2? --------------------- The time between releases.

That doesn't make any sense; there isn't a fixed time between releases ala Chrome or OpenBSD. If you bump things back, earlier releases will happen sooner.

Re: What’s Up With All These Changes in Rails?

#108

Post by awj »

jarin wrote: post #84
chollida1 wrote: post #30

Earlier quoted context omitted.

> (1) If you are a Rails developer you need to be a full-time Rails developer and not do too much else. You can't do Rails and a bunch of other things because Rails will take up a lot of your time. I'm glad to see someone else say this. I don't use rails often, nor am I a "front end" developer by trade. I have put together some simple web apps using rails, but it seems that each time I go back to rails and try to use…

I think most Rails developers I know are also full-time designers, JavaScripters, database admins (SQL and NoSQL), server admins, IT people, project managers, forum posters, Stack Overflow answerers, social media gurus, SEO/SEM experts, and salespeople. It just sort of comes with the territory that being a good Rails developer means being a polymath.

Yeah, as a Rails developer I seriously doubt any of us are full time any of those things. I've met people that actually do full time JavaScript dev and DB admin, the knowledge difference between us is staggering.

Rails developers need to wear lots of hats to get their jobs done. They need to be "good enough" at each of those. That, in itself, is a difficult enough task. You don't need to go trying to claim they do full time level work for six different jobs.

Re: What’s Up With All These Changes in Rails?

#109

Post by [deleted] »

ssmoot wrote: post #105
aaronblohowiak wrote: post #88

Earlier quoted context omitted.

The mono C# compiler should pre-evaluate the loop and just set x to the computed value. You'd have to look at the bytecode to verify, but i would be shocked if mono didn't do that. Still, it should take the blink of an eye, not a chin-scratch.

I get that it could, is there a reason you think it actually does? Either way, nice observation. Interesting.

[deleted]

Re: What’s Up With All These Changes in Rails?

#110

Post by aaronblohowiak »

ssmoot wrote: post #105
aaronblohowiak wrote: post #88

Earlier quoted context omitted.

The mono C# compiler should pre-evaluate the loop and just set x to the computed value. You'd have to look at the bytecode to verify, but i would be shocked if mono didn't do that. Still, it should take the blink of an eye, not a chin-scratch.

I get that it could, is there a reason you think it actually does? Either way, nice observation. Interesting.

I have no first-hand evidence of the behavior of mono, but constant expression elimination is a common compiler optimization.
Post reply on HN