I know there are a lot of existing questions on Django hosting etc but my question is whether there is a technical reason why RoR hosts are easier to get by than Django hosts. Is there something in the technology itself or the architecture that makes it more of a hassle for providers to host and maintain?
It's both seemingly easier to find better free hosts for RoR than for Django (10mb from alwaysdata really doesn't allow for a lot and App Engine isn't a vanilla Django) and easier to find decent RoR hosts for 2$/month packed with features than for Django.
Is the reason technical or just because of market share/timing?
Thanks,
Xiao
Let's face it, free hosts are nowhere near good, and nor are very cheap ones.
If you want a decent host, you will have to pay a decent amount.
On the other hand, rails is nearly 1 year older than django, and started to popularize way earlier than django did. Also, php being older and popularized earlier, it seems a good reason for rails to be more popular with hosts than django.
Django it is not more difficult to host than RoR.
IMHO this offering delta is there mostly because of the market share the RoR has compared to Django.
If it is true that rails is older than Django, it's also true that Python is older (and used by more people) than Ruby.
Also a technology like WSGI that makes things easier for web applications was already there when something similar came out for Ruby (Rack).
I think it's less timing and more community push, myself. There is an extremely active and vocal community behind Rails. Just go down to your local bookstore and take a look at the books there. You'll probably find 5x the amount of Rails books that you will find over Django. As it is said, the squeeky wheel gets greased. There is a strong vocal minority of Rails users, and that means that people will cater to them on shared hosts, because otherwise they'll have to listen to a lot of requests that keep asking for it.
Not to say that time-in-market doesn't have something to do with it, I just find that the community behind any given technology has a lot to do with it's level of adoption in different business models.
Also, any host that hosts Ruby apps can host just about any of the major frameworks, as long as they are Rack compatible. So for having to deal with Rails, they usually get support for Sinatra, Ramaze, etc, for free. Instead of just supporting Django.
Related
So I have a lot of smaller clients that want more simple websites. This is very common and even more common is the mess of code that I get from their last developer who used wordpress. Since I am trying to hone my rails skills, I would prefer to just redo the site in rails. The biggest problem I've encountered though is server hosting costs.
It is really hard to convince someone to go from their $5-10 a month cost for their servers to $34 with something like heroku or amazon EC2. So my question is how can I effectively use rails to rebuild these wordpress sites without incurring more costs on the client?
Some options I have thought of are:
Find a shared web hoster and figure out how to get rails on it (doesn't seem like a good idea due to lack of rails support by these host sites like godaddy, host monster, etc).
Use a scalable server like EC2 and put multiple apps on it, and since most of the sites are low traffic it should balance out to a reasonable cost.
Submit to the popularity of wordpress
Some of the example sites are a store, blog/store, and a marketing website.
There's nothing wrong with honing your skills on the job but you also have to be considerate of the clients needs.
Just because you'd prefer to redo the site in rails doesn't mean that's the best thing for the client. If their site is running smoothly on their cheap hosting do they really want to increase their monthly outgoings to support a platform that they didn't want in the first place.
There's very little functionality the client might need that they can't get from WordPress and the examples you gave certainly don't suggest rails is necessary.
I'd suggest keeping them on WordPress and seeking clients who need a rails developer.
Here's my 2 cents. Stick with WordPress. If you're trying to hone your Rails skills, start a side project. But if you try to convert these sites to Rails, you're going to be incurring a lot of cost to the client (your time), and hosting. As you mentioned, hosting a Rails app costs much more.
It's hard to justify that cost just to hone your skills unless you could convince the client that, in the long term, they will save a great deal of money, either by the reduced overhead on code maintenance, or they're trying to do something that Rails can do that WordPress genuinely can't. With the ubiquity of high quality WordPress plugins, you'd really have to dig for a functionality that you absolutely cannot do with WordPress that you can with Rails, though there are some.
Sure, Rails is much more pleasurable to work in than WordPress, but if these sites are for clients, you can't just factor in developer happiness. You need to be adding value for your customer, and building a site in Rails because it's more fun to work in adds little value for your customer.
Honestly, if they're a few static sites, then keep them on WordPress. You could start new clients out on a Rails-based CMS (or a custom solution, if you can sell them on it and you're sure you can make it worth their money), but my advice would be that it's not worth the cost to you or to them to build the sites in Rails just for the sake of building the sites in Rails.
I want to make a community based site, which is Drupal's strength. However I also want to try other frameworks, especially Rails.
One of the best things about drupal is its huge modules library. If I were to switch to Rails, would I be able to find similar functionality freely available as plugins, or would I have to rebuild?
Does Rails have the equivalent of (as plugins or gems):
CCK/Fields?
Node Reference?
Views / Views Relationships?
PathAuto?
Threaded Commenting?
Multisite Functionality?
Apache Solr (or equivalent) Integration?
Thanks.
I'm afraid you'll probably hear this answer a lot, but it's not a suitable comparison.
Drupal is a ultimately a CMS, Rails is a framework. Apples to oranges, or perhaps even Apple Juice to oranges. Out of the box, you fire up Drupal and it does 'things': it has a database structure, the concept of nodes, interfaces blah, blah. If you fire up Rails you have an empty project.
As far as I know there isn't a "Drupal-on-Rails" project that would be a suitable equivalent. However, I can attest to the fact that there is an awful lot of Ruby/Rails community and O/S work out there and you might find something suitable. I'd also say that the level of modularity in Ruby and Rails tends to mean that the range of plugins/modules/gems one can use is much greater.
My personal $0.02. If Drupal does what you need, just use Drupal: it's mature and has a great community. It's never a good idea to try to port Project X over to a new language as a learning exercise because you'll inevitable fall into the "Well that's how it's done in language X!" trap and become disenchanted with the new system.
If you're wanting to learn Rails (which you should, it's awesome) I'd suggest you'd be best working on a small project and seeing what the ecosystem offers before deciding if it's suitable for the needs of your bigger projects.
I have to second what Govan said, but add to it.
With Drupal, unless you really want to get into building your own modules and extensions you are really interacting with an application. Even when you start using CCK, all you are really doing is flipping switches, filling in forms and defining new options for content on the site.
Ruby on Rails is two things, and neither of them bares much similarity to Drupal. You asked "How hard is it really?". To answer that you need to understand what both Ruby and Rails are. Ruby is a programming language designed to make the life of the object purist programmer simpler and more pleasant. So, the first part of how hard is it is simply to answer "how long do you feel it would take you to learn a completely new programming language, like PHP but different".
Rails is an 'opinionated' framework. It's opinionated in that it lays out how a Ruby web project should be structured, as well as providing multiple APIs for everything from database access to web presentation. To answer the "how hard is it" question for Rails then (assuming you know Ruby by this point), you have to answer how much do you need to learn about cacheing, database design, page design, RESTful programming etc etc.
It's not a short journey. you asked if there is an equivalent to CCK for Ruby and Rails which implies to me that at this point your knowledge of programming is somewhat limited. Ruby and Rails interact with the database. CCK lets you define things in a database. Thus, with Ruby and Rails you are effectively bypassing the wonderful dialogs and forms that CCK provides you with and doing the data definition bits yourself, by hand, in code.
From experience, when I've hired experts in another programming language and framework into my Rails teams, it has taken them between 1 and 3 months to get productive, and a further 3 to 6 months for their productivity to start to raise and approach that of the Rails experts on my team.
Thus, in your particular case, I would not recommend a switch away from Drupal to Ruby on Rails.
Drupal (core) on ohloh (130k lines of code) is estimated to be 34 years of work worth.
Drupal (contributions) on ohloh (modules for Drupal 4-6 (7M lines of code)) is estimated to be 2113 years of work.
That is the power of a community, and that is something that you can never replicate. I remeber there was a guy, who tried to port Drupal to python calling it drupy, but that project died before something useful ever came out of it. Even if you copy the code, you can never copy the community.
The thing you need to realize, is that each community is different. So even if you find a project that can solve your code needs in a RoR or a different language/framework, it will never be like Drupal and vice versa.
So don't try to find a replacement for Drupal, but go explore and try new things. You might end up learning new things, that you can use for your Drupal projects.
I've read this times and times again that people saying comparing drupal an ror is comparing apple to orange which is wrong.
I think the saying itself BS. Yes we want to compare apple to orange and find out which is better. We even want to compare apple to steak. Said that, they are different. Yes, we all know. I have limited experience with either. I first thought Drupal was great and can help me build the website I wanted overnight (or over a week or month) then it didn't happen (not blaming Drupal).
My impression is that, Drupal maybe still great but it has a learning curve and needs a lot of other knowledge or talents to use it well and tweak it. RoR on the other hand is a more general framework and needs programming (Drupal needs too actually).
If you are more of a web designer person with a little PHP maybe Drupal is better fit.
If you are more of a web developer type don't want to spend time looking for modules and make them work but rather do them yourself (not really from ground up) then maybe RoR is for you (with the same amount of learning). So yes they are both good for different purpose, background, etc.
For now I will go with RoR (or dJango and other ORANGEs). My 2 cents.
Rails, since version 3.0, has officially adopted the once-controversial engine way of incorporating third-party apps. this is roughly the equivalent of Drupal's modules/plug-ins, from a 10k foot perspective. To build a community-based site, you could make use of an engine called, appropriately enough, "Community Engine." http://communityengine.org/features.html"
The Rails ecosystem doesn't have anywhere near the same number of modules Drupalists have available to them, but there are enough good quality ones to cover the chief basics.
Drupal has so many strong areas, its hard for just one or two people to recreate it in a decent amount of time with any language. PHP, Ruby, Python, etc.
You have the core node system, taxonomy, aliasing, menus, users, permissions, and modules, the database api, and form api, among others.
You'd have to know how to assemble all these pieces independently and create the structure necessary for it to all work together.
It would take more than 'a few hours'. I would say, even if you are a ROR master, you're looking at a year to two years of solid consistent work to get the best parts of Drupal for a new system.
I just saw that whitehouse.gov is using drupal as a CMS and portal technology.
One of the advantages of drupal seems that it is easy to add plugins and that programming is minimum, i.e. that re-inventing the wheel is at minimum. That is actually exactly the DRY philosophy of Ruby-on-Rails. So:
What are the drawbacks of drupal?
What would Rails or other Ruby based technologies disqualify as portal technology for whitehouse.org (or other CMS portals) ?
What are the drawbacks of drupal?
This is really a quite subjective question in relation to Ruby and Rails. Drupal is a solid content management option and really shines for community-oriented sites. It is useful for general purpose content management for non-portal sites as well. The drawbacks would be that it is built on PHP, if you are a Rubyist then that is a significant drawback. Additionally it is a beast of a project if you are looking at just the core. The API is quite large which is fitting for a project like Drupal, but this can make getting substantial customization done into a lot of coding work. Also, because of the whole architecture of Drupal there is no clear separation of data types unless you write a custom module that makes a clear separation and while this is in keeping with the "Drupal way" it is a little odd to some to think of EVERYTHING as a node or within the structure of Drupal's Taxonomy system or the like.
The biggest drawback to Drupal really can be best summed up this way: in order to make effective use of Drupal you really need to know and understand Drupal in a way that you don't for a CMS system like Radiant; but Radiant is nowhere near as complex as Drupal.
What would Rails or other Ruby based technologies disqualify as portal technology for
whitehouse.org (or other CMS portals) ?
Rails is rather dissimilar from Drupal in that it is not really a content management system at all but a more general purpose application framework. You can use Drupal in ways similar to Rails, but Drupal is really much more than what Rails is. Better comparisons could be made between Drupal and say Radiant or BrowserCMS or some of the other Ruby/Rails CMS packages. There are Ruby/Rails portal systems out there but few match the bulk of Drupal and it's community. The most comparable options in the Ruby ecosystem only match bits and pieces of what Drupal can do, but that is because Drupal is that massive a project and a community. Drupal is a swiss army knife plus some for doing sites on the web. Ruby doesn't have a truly similar project out there because most Rubyists don't see any reason to duplicate Drupal's girth.
I would recommend the following projects as things to look at if you are considering use Ruby in place of Drupal (most of these Ruby projects will cover less than Drupal but fit closer with your site's actual needs):
Radiant
BrowserCMS
Lovd by Less
Community Engine
Quite subjectively, I find the Drupal administration interface a bit clunky. You can try it out for yourself without actually installing Drupal at opensourcecms.com. That being said, there seem to be a great momentum in Drupal community at the moment, and it's starting to become a really full-featured CMS.
Comparing Rails to Drupal is somewhat like comparing apples to oranges. Rails is an application framework and Drupal is a CMS (although with a kind of application framework included).
allesklar, what is wrong with the extension system within Radiant? There are plenty of Rails CMS out there already. I suspect contributing to an established system to improve it would be more productive for the community at large than creating yet another niche CMS.
I'm a Rails developer so I'm all for Rails solutions but presently there is no Rails CMS that comes any close to a CMS such as Drupal in terms of functionality and plugins.
I attribute this partly to the 'less is more' philosophy advocated by 37signals.
Wordpress, Drupal, and others go for 'as many features as possible' and doing such end up attracting masses of users who will find that these products do answer their needs.
I've been playing with the idea of, like many others, starting a Rails based CMS system with plenty of features and a good plugin architecture. No time to work on this yet though between client work and development of an hosted application I'm working on.
I just found this site:
drupal and rails
If you are looking for portal technology built in Ruby, a relatively new candidate to consider would be EngineY. EngineY was originally built as a social networking framework but also has features that make it a viable candidate as a traditional portal. EngineY's concept of a 'widget' is similar to a traditional portal's portlet. There is a Managed Content widget included with EngineY that lets you create a portal made up of managed content. Best of all is that EngineY is very actively maintained and is evolving and improving daily.
I'd like to go into Django with Python, but it seems that some hosting companies like DreamHost, Netfirms, they both offer Ruby on Rails in the basic hosting package, but not Django. They only list Python, but not the framework. So does that mean if I use Django, I will need to look for companies that support Django, or can I simply add the Django files to my directory and it will work without using any other support?
Check out Djangofriendly.com for a list of hosts that are friendly to setting up Django (not that you can't do it with many other hosts, of course).
Personally, I have a few Django apps hosted on Webfaction and they are absolutely amazing.
Dreamhost does support Django!
And here's a list of hosting companies which support Django, and as you see, most major companies support it.
It would be harder in the sense that the number of choices you have will be smaller. But the reality is that you need only one host anyway.
I highly recommend Webfaction as my experience with them has been very good. They support Django out of the box with very little configuration necessary on your side.
Check these lists for Django hosts:
http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
http://djangohosting.org/
Be aware that most shared hosting packages will not be suitable for Django, because of the need to restart the server whenever you make changes to python code - most don't allow this. Webfaction is a notable exception - I am using them for several Django projects, and would second the recommendations above. You barely notice it's a shared host.
But you might want to consider virtualized hosting. I also have some projects hosted at Slicehost. The prices are comparable to a shared host and you have complete control over your server. This also means, of course, that setting things up is less one-click, although they provide great step-by-step tutorials.
Maybe you could look into Googles app engine if you want to do python web development. They can handle all the hosting for you.
Yes!
The standard hosting packages are either Windows/ISS or Linux/php/perl/Mysql.
There are a few specialist Django/python hosting packages, but, your best bet is
to get a Linux VPS (Virtual Private Server) package which gives you root access.
You can then install exactly what you require. Prices start at less $10 a month
for a basic low bandwith not much disk space package.
It depends on compared to what. If it is compared to Rails, it will be harder just because of the buzz around Rails and it is quite likely a "basic" package would include Rails before Django, so if that cost factor matters, be aware of it, but there is pleanty of competition for Django hosting, so the lack of hosting isn't a reason to avoid it.
PHP is much more popular to host at the basic level, if hosting drives the technology decision.
I'm a big fan of ruby on rails, and it seems to incorporate many of the 'greatest hits' of web application programming techniques. Convention over configuration in particular is a big win to my mind.
However I also have the feeling that some of the convenience I am getting is coming at the expense of technical debt that will need to be repaid down the road. It's not that I think ROR is quick and dirty, as I think it incorporates a lot of best practices and good default options in many cases. However, it seems to me that just doesn't cover some things yet (in particular there is little direct support for security in the framework, and plugins that I have seen are variable in quality).
I'm not looking for religious opinions or flamewars here, but I'd be interested to know the community's opinion on what areas Rails needs to improve on, and/or things that users of Rails need to watch out for on their own because the framework won't hold their hand and guide them to do the right thing.
Regardless of framework the programmer needs to know what she's doing. I'd say that it's much easier to build a secure web application using something as mature, well designed and widely adapted as Ruby on Rails than going without the framework support.
Take care with plugins and find out how they work (know what you do, again).
I love Rails too, but its important for us to understand the shortcomings of the framework that we use. Though it might be a broad topic addressing these issues wont hurt anyone.
Aside from security issues, one other big issue is DEPLOYMENT on Shared Hosts. PHP thrives in shared hosting environments but Rails is still lagging behind.
Of course most professional Rails developers know that their apps need fine-tuned servers for production and they will obviously deploy on Rails-Specific hosts.
In order for Rails to continue success the core team should address this issue, especially with Rails 3.0 (Merb +Rails) coming..
An example of this is simple: I have a bluehost account, and i noticed the Rails icon in my cpanel. I talked to the bluehost support and they said its more or less a dummy icon, and that it doesn't function properly.
Having said that any professional who wanted to deploy a Rails App would not use bluehost. , but it does hurt Rails, when hosts say that they support it and then users run into problems which their support know nothing about..
The article you refer to defines technical debt as
[the] eventual consequences of
slapdash software architecture and
hasty software development
With rails, any development that is not test driven incurs technical debt. But that is the case with any platform.
At an architectural level Rails provides some deployment challenges. A busy site must scale with lots of hardware or use intelligent caching strategies.
My advice to anyone adapting Rails would be to:
use TDD for all your development
verify the quality off any plugin
you use by reading its tests. If
they are not clear and complete,
avoid the plugin
read "Rails
Recipes" and "Advanced Rails
Recipes" (Advanced Rails Recipes has
a good recipe for adding
authentication in a RESTful way)
be prepared to pay for hardware to scale your site (hardware is cheaper than development time)
From my experience, by far the biggest tolls you end up paying with RoR are:
Pretty big default stack (not counting plugins you might be using)
Updating models tends to be a pain in the ass, at least in production servers.
Updating Rails or Ruby themselves is a bit more complicated than it should, but this differs depending on your server setup.
As ewalshe mentioned, deployment is sometimes a drag, and further down the road, should you require it, scaling gets a bit iffy, as it does with most development frameworks.
That being said, I'm an avid user of RoR for some projects, and with the actual state of hardware, even though you do end up paying some tech debt to using it, it's almost negligible. And one can hope these issues will be reviewed eventually and solved.
With any level of abstraction there is a bit of a toll you pay - genericized methods aren't quite as fast as those specific to something built just for your purpose. Fortunately though, it's all right there for you to change. Don't like the query plans that come out of the dynamic find methods? write your own, good to go.
Someone above put it well - hardware is cheaper than developers. I'd add "at a sufficiently low amount of hardware"
I'm reading Deploying Rails Applications and recommend it highly to answer your concerns.
The book is full of suggestions to make life easier, taking a deployment-aware approach to your Rails development from scratch, rather than leaving it to later.
I don't think the choice of RoR implies a technical debt but just reading the first few chapters alerted me to practices I should be following, particularly on shared hosts, such as freezing the core rails gems so you can't be disrupted by upgrades on the host.
The 30-page chapter on Shared Hosts includes memory quote tips such as using multiple accounts (if possible) with one Rails app per account. It also warns about popular libraries such as RMagick possibly pushing your memory size to the point where your processes are killed (such as a 100MB limit, which it suggests some hosts periodically apply).