4 ms·

You are joking right, "Try not to stuff your app with everything you can possibly think of." Like providing a admin interface on Refinery as well as authentic

by tmo9d 14y ago

You are joking right, "Try not to stuff your app with everything you can possibly think of." Like providing a admin interface on Refinery as well as authentication with Devise is "everything and the kitchen sink". I think you may be trying to defend something.

grey-area 14y ago
Have you used Refinery? I have and wouldn't base an app on it, or even use it again for a CMS - frankly you could build the same admin features better in Rails in a couple of days, and tailor them properly to your application. Refinery is not a good model of a rails app and is probably the main reason for his problems or perception that Rails is heavy - it was a mistake to try to base an app on it and most of his gripes seem centered on that - there's a lesson there and it's not about Rails. Rails has become lighter with 3.x and will become lighter still with 4.x - they're dropping a lot of unnecessary stuff and trying to pare it down to the minimum - an admirable direction and quite the opposite to Java, which makes this article all the more baffling. Of course it's not the perfect framework and there are plenty of options, but the complaints of the article are histrionics. The laundry list of possible technologies in the article is absurd - RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New Relic, Foreman, AMQP, and Honeybadger, Heroku. You can get started with rails on a cheap VPS and serve your first few hundred thousand users with the following very simple stack: Apache, Ruby, Passenger, Rails. Setup is a few lines in your package manager of choice, writing the app is straightforward and requires none of the software above, maintenance is running aptitude update and bundle update now and then. Out of the stack above, Devise is quite a nice authentication solution and is the only one I'd recommend, but it's easy to roll your own, as to the rest of his list, if you don't need it, don't bother using it, none of it is required.
- tmo9d 14y ago
  "An admirable direction and quite the opposite of Java." What are you talking, specifics please? Is Java a framework with features comparable to Rails? Why is the laundry list of technologies absurd, these are the technologies that I run a business on. I think what's absurd is the level of reaction in your comment. Rails people now have this defensive reaction, and I've noticed it in person as well. It reminds me of the reaction of Java zealots in 2007. It really does. "Oh, really, you couldn't be serious, I mean it's absurd to think that Ruby...." It wasn't absurd to challenge, and neither is this challenge.
  - grey-area 14y ago
    Firstly, apologies for the harsh tone and references in the 3rd person as I see from your other comments that you are the author of the article. "An admirable direction and quite the opposite of Java." What are you talking, specifics please? Is Java a framework with features comparable to Rails? I admit this was sloppy wording, however your article is called 'Rails, You Have Turned into Java.' :) I was comparing Rails 4 (removes lots of features/bloat), with Java Frameworks which do not have a reputation for slimming down... Of course I'm sure there are some minimal Java web frameworks out there too (sorry not familiar with many). Your article is somewhat provocative and not representative of the experience of many with Rails so I wouldn't be surprised if you encounter a defensive reaction to this sort of sentiment. That's to be expected, as was the reaction of those using Java frameworks to DHH's blowhard rhetoric when he started out with Rails. Why is the laundry list of technologies absurd, these are the technologies that I run a business on. They're absurd as a criticism of Rails because many of them are completely external to Rails, not required to run a website/app, and some of them are not the right choices IMHO. Rails does not require any of these components to run websites even at scale. Sure some of them might be useful, but none are essential or intrinsic to Rails. Forgive me but I think the choice of RefineryCMS was a mistake, and if you back out of that mistake, you'd find Rails a lot more forgiving, a lot lighter, and a lot more suited to what you want to do if you're writing a large webapp with lots of components (or several interacting webapps). Problems with engines, subapps, conflicting routes etc are all based on this, and simply don't occur in most Rails apps. I've used it as a CMS for some clients and regret having done so in retrospect - it's not terrible standalone (also not great) but I can see how integrating it with an app would be a nightmare. You don't need to use meta-frameworks built on Rails to build an app, in fact I'd say it's a mistake, use a few discrete gems like devise, and just build what you want.
lobster_johnson 14y ago
I am not joking. There is absolutely no reason to put an admin interface in an app. Here is an example applicaion, let's call it Foo. It's a blogging tool: * FooCore: This is an API exposing the data Foo that works with, and the ways to change that data. It has a Blog model, a Posting model and an Author model. It has endpoints like "GET /api/blogs", "PUT /api/blogs/:id/postings" and "GET /api/authors/:id" to create blogs and postings. It has no UI. * FooApp: This is the user-facing frontend application. It serves the main site in HTML, JS, CSS and whatever other. It renders blogs from FooCore by calling is API. It has no logic other than presenting the UI and acting as an MVC controller and view (the M being the API). It calls the API both from its server app, as well from the browser via XMLHttpRequest. * FooAdmin: This is the user-facing admin frontend app. It serves the "back office" admin UI for managing blogs and posts and users. We now have a very elegant app where the division between the parts is crystal clear. The admin UI's requirements do not affect the public UI's requirements or vice versa. The underlying data model can't build up weird UI cruft because there is no UI to let sloppy devs screw it up with their laziness. (Need a new UI -- say, you want to accept blog postings via email? Create a new app, FooEmailApp that handles only this interaction using the same API. Want to accept blog postings by fax? Create a new app, FooFaxApp. Neither frontends will have code that bogs down the other UIs. If you decide fax is dead, just delete the entire app.) (And you can extend your own ecosystem of services organically. Need role-based permissions? Create an app for it, and wrap every HTTP verb with a check against the permission app.) Anyway, the above app is not complete; you want login via Twitter, so we add Checkpoint into the mix. This happens: 1. When FooCore wants needs a user, it looks in its session cookie and determines which user it is. 2. If there is no user, we create a redirect to Checkpoint's /login/twitter. Checkpoint does the necessary OAuth interaction behind the scenes, stores the credentials in its store, update its own cookie, and redirects back to FooCore. (Remember, Checkpoint has no UI. It just redirects to Twitter, which displays the usual OAuth login/authorization dialog.) 3. FooCore can now use Checkpoint's cookie to determine who the logged-in user is, and it can ask Checkpoint for data such as the user's name and email. It can also create an internal User object that represents FooCore's own data about the user, such as blogs and postings. The upshot: The app knows nothing about authentication. It outsources everything. It can focus on the important stuff. This modular separation of concerns into separate apps sharpens your focus as a developer, and forces you to think about the data and the interactions that are necessary. Because of HTTP/REST's relative poverty, everything becomes a verb, and every verb must be designed separately. Two other benefits: It forces you to think of reuse, since every feature becomes an opportunity to reuse a modular component. Secondly, it forces you to think of "presentation" and the divison between ugly internal state and public state, because every interface becomes much more exposed to the world; when an app becomes an API, you are subject to more scrutiny than if you were tucking the stuff away in some class somewhere in your app. No, I'm not kidding. Back in 2006 we tried the old model of putting everything and kitchen sink (login/auth, normal UI, admin UI, promo site, email notifications, role-based permissions, statistics, visualizations, image upload etc.) into our apps. The model does not scale. The benefits of a "many small apps" model have been obvious even for relatively small applications. I'm not defending anything. If anything I'm attacking? :-)

by tmo9d 14y ago

grey-area 14y ago

Have you used Refinery? I have and wouldn't base an app on it, or even use it again for a CMS - frankly you could build the same admin features better in Rails in a couple of days, and tailor them properly to your application. Refinery is not a good model of a rails app and is probably the main reason for his problems or perception that Rails is heavy - it was a mistake to try to base an app on it and most of his gripes seem centered on that - there's a lesson there and it's not about Rails. Rails has become lighter with 3.x and will become lighter still with 4.x - they're dropping a lot of unnecessary stuff and trying to pare it down to the minimum - an admirable direction and quite the opposite to Java, which makes this article all the more baffling. Of course it's not the perfect framework and there are plenty of options, but the complaints of the article are histrionics. The laundry list of possible technologies in the article is absurd - RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New Relic, Foreman, AMQP, and Honeybadger, Heroku. You can get started with rails on a cheap VPS and serve your first few hundred thousand users with the following very simple stack: Apache, Ruby, Passenger, Rails. Setup is a few lines in your package manager of choice, writing the app is straightforward and requires none of the software above, maintenance is running aptitude update and bundle update now and then. Out of the stack above, Devise is quite a nice authentication solution and is the only one I'd recommend, but it's easy to roll your own, as to the rest of his list, if you don't need it, don't bother using it, none of it is required.

tmo9d 14y ago
"An admirable direction and quite the opposite of Java." What are you talking, specifics please? Is Java a framework with features comparable to Rails? Why is the laundry list of technologies absurd, these are the technologies that I run a business on. I think what's absurd is the level of reaction in your comment. Rails people now have this defensive reaction, and I've noticed it in person as well. It reminds me of the reaction of Java zealots in 2007. It really does. "Oh, really, you couldn't be serious, I mean it's absurd to think that Ruby...." It wasn't absurd to challenge, and neither is this challenge.
- grey-area 14y ago
  Firstly, apologies for the harsh tone and references in the 3rd person as I see from your other comments that you are the author of the article. "An admirable direction and quite the opposite of Java." What are you talking, specifics please? Is Java a framework with features comparable to Rails? I admit this was sloppy wording, however your article is called 'Rails, You Have Turned into Java.' :) I was comparing Rails 4 (removes lots of features/bloat), with Java Frameworks which do not have a reputation for slimming down... Of course I'm sure there are some minimal Java web frameworks out there too (sorry not familiar with many). Your article is somewhat provocative and not representative of the experience of many with Rails so I wouldn't be surprised if you encounter a defensive reaction to this sort of sentiment. That's to be expected, as was the reaction of those using Java frameworks to DHH's blowhard rhetoric when he started out with Rails. Why is the laundry list of technologies absurd, these are the technologies that I run a business on. They're absurd as a criticism of Rails because many of them are completely external to Rails, not required to run a website/app, and some of them are not the right choices IMHO. Rails does not require any of these components to run websites even at scale. Sure some of them might be useful, but none are essential or intrinsic to Rails. Forgive me but I think the choice of RefineryCMS was a mistake, and if you back out of that mistake, you'd find Rails a lot more forgiving, a lot lighter, and a lot more suited to what you want to do if you're writing a large webapp with lots of components (or several interacting webapps). Problems with engines, subapps, conflicting routes etc are all based on this, and simply don't occur in most Rails apps. I've used it as a CMS for some clients and regret having done so in retrospect - it's not terrible standalone (also not great) but I can see how integrating it with an app would be a nightmare. You don't need to use meta-frameworks built on Rails to build an app, in fact I'd say it's a mistake, use a few discrete gems like devise, and just build what you want.

lobster_johnson 14y ago

I am not joking. There is absolutely no reason to put an admin interface in an app. Here is an example applicaion, let's call it Foo. It's a blogging tool: * FooCore: This is an API exposing the data Foo that works with, and the ways to change that data. It has a Blog model, a Posting model and an Author model. It has endpoints like "GET /api/blogs", "PUT /api/blogs/:id/postings" and "GET /api/authors/:id" to create blogs and postings. It has no UI. * FooApp: This is the user-facing frontend application. It serves the main site in HTML, JS, CSS and whatever other. It renders blogs from FooCore by calling is API. It has no logic other than presenting the UI and acting as an MVC controller and view (the M being the API). It calls the API both from its server app, as well from the browser via XMLHttpRequest. * FooAdmin: This is the user-facing admin frontend app. It serves the "back office" admin UI for managing blogs and posts and users. We now have a very elegant app where the division between the parts is crystal clear. The admin UI's requirements do not affect the public UI's requirements or vice versa. The underlying data model can't build up weird UI cruft because there is no UI to let sloppy devs screw it up with their laziness. (Need a new UI -- say, you want to accept blog postings via email? Create a new app, FooEmailApp that handles only this interaction using the same API. Want to accept blog postings by fax? Create a new app, FooFaxApp. Neither frontends will have code that bogs down the other UIs. If you decide fax is dead, just delete the entire app.) (And you can extend your own ecosystem of services organically. Need role-based permissions? Create an app for it, and wrap every HTTP verb with a check against the permission app.) Anyway, the above app is not complete; you want login via Twitter, so we add Checkpoint into the mix. This happens: 1. When FooCore wants needs a user, it looks in its session cookie and determines which user it is. 2. If there is no user, we create a redirect to Checkpoint's /login/twitter. Checkpoint does the necessary OAuth interaction behind the scenes, stores the credentials in its store, update its own cookie, and redirects back to FooCore. (Remember, Checkpoint has no UI. It just redirects to Twitter, which displays the usual OAuth login/authorization dialog.) 3. FooCore can now use Checkpoint's cookie to determine who the logged-in user is, and it can ask Checkpoint for data such as the user's name and email. It can also create an internal User object that represents FooCore's own data about the user, such as blogs and postings. The upshot: The app knows nothing about authentication. It outsources everything. It can focus on the important stuff. This modular separation of concerns into separate apps sharpens your focus as a developer, and forces you to think about the data and the interactions that are necessary. Because of HTTP/REST's relative poverty, everything becomes a verb, and every verb must be designed separately. Two other benefits: It forces you to think of reuse, since every feature becomes an opportunity to reuse a modular component. Secondly, it forces you to think of "presentation" and the divison between ugly internal state and public state, because every interface becomes much more exposed to the world; when an app becomes an API, you are subject to more scrutiny than if you were tucking the stuff away in some class somewhere in your app. No, I'm not kidding. Back in 2006 we tried the old model of putting everything and kitchen sink (login/auth, normal UI, admin UI, promo site, email notifications, role-based permissions, statistics, visualizations, image upload etc.) into our apps. The model does not scale. The benefits of a "many small apps" model have been obvious even for relatively small applications. I'm not defending anything. If anything I'm attacking? :-)