Hello i want to use NoSql database in my rails/django application for learning point of view. What the various things i should kept in mind.
Any tutorials?
things to be kept in mind?
Any Tips like do and don't?
EDIT
I am fully flexible. I want to learn. I know php,rails,django.I want to create some application using Nosql database as learning point of view. cassandra is just an example.Any other Nosql will also work.
The django-nonrel scene is a good place to start reading up
Daniel Kehoe has a nice tutorial on using Rails 3, Devise and MongoDB.
http://github.com/fortuity/rails3-mongoid-devise
Addressing the Rails part of your question.
I would say that it is definitely viable use Ruby on Rails with Cassandra so long as you are comfortable with giving up some of the ActiveRecord idioms you may have become accustomed to. But that is probably true to a great or lesser extent with any marriage of Rails and a NoSQL datastore. The closest thing to ActiveRecord that is emerging is the Cassandra Object gem but this is still a work in progress by the author's admission. The most stable interface seems to be the Cassandra gem but this is a relatively low level API.
If you are interested in Cassandra from a learning perspective or you have identified it as the best option for an application you are building then well and good. Assuming you select Rails and Cassandra you can rest assured that the support for these will only improve and probably quite quickly given the growing interest in NoSQL and in Cassandra in particular.
However if you have other options which would work and Cassandra is only one of them then I would enter some caveats. Firstly, Rails on Cassandra is an evolving entity so you may encounter instability or things you expect to work don't work at all or completely differently that you expect. Secondly, and related to this, is that there are very few Rails on Cassandra deployments out in the wild right now so getting support from forums this will be all the more difficult. You may end up on your own with something when you can't afford to be. You may end up having to roll up your sleeves and pitch in to help with supporting the code yourself, which may be no bad thing.
Personally, I would wait to see how this picture pans out before I'd go with Cassandra unless I felt that nothing else could do the job as well. If it's for learning then I'd say go ahead. Can be a lot of fun being at the bleeding edge of things like this.
References:
Real world Ruby and Cassandra
Up and running with Cassandra
This is a example app for django with cassandra and there is an interesting post about django-nonrel and finally a feed about cassandra
You must keep in your mind: The ORM of django doesn't work completely because the difference between SQL backend and no-SQL backend, some thinks like joins, complex filters and things like that. You must change your mentality about of database.
in Django the dev team are working for official no-SQL support
Related
For a new web project like kijiji, if I want a faster development(the faster the better), which one should I go with? I know some ruby and javascript, but not an elite and never did a project on either of them. Coding is my hobby, not my job. Any suggestion? Thanks in advance.
Express is more along the lines of Sinatra, not Rails. It's much smaller, simpler and to the point than Rails. I don't think it's a fair comparison.
But what the heck, here are my thoughts while I'm here:
The Node community is fast growing, but it's still nowhere near the size or momentum of the Rails community. Overall you'll probably find more help and more kindred spirits with Rails. Node and Express will require more figuring out things on your own.
In my experience, the Rails/Ruby community have much better tools for testing than Node/Express. Hell, they have the best tools for this out of any community I've seen :)
Express is not well documented at all. The guide on their page is a decent start but it's just that. You will find yourself digging through code, obscure blogs and github repos looking for info.
Data access? It's built right into Rails and a core part of it. Express isn't concerned about your data layer at all (again it's more like Sinatra). You will need to decide on what kind of data access/layer you want to go with and see what kind of support Node has for it.
I really like both Rails and Express. But if the project was of any decent size, I'd probably pick Rails myself.
They are both vastly different so it depends on your goals. I suggest Rails as it's more mature and you'll get better community support if you have any issues. Rails's Active Support Core Extensions will also give you a ton of useful helpers which could save you a lot of time developing a web app.
Otherwise just go for the one that interests you the most.
I have some (I think) really great ideas for an online strategy game similar to Travian. There's some content that I haven't yet figured out and some other challenges that I don't know of yet.
This is quite a big project and perhaps too heavy for one person that isn't a skilled web developer (yet). I'd still like to give it a shot, but I'm having trouble choosing a platform. The world "scales" has been thrown around a lot lately and I've seen Ruby on Rails being bashed because it doesn't scale well, so I've come here to get some answers.
I like Ruby on Rails, both Ruby and Rails. I'm certainly no expert at it but I love working with it. I have also worked with Python + Django before and also with PHP (which I am not fond of.)
Ideally the game would have, let's say, 7000 players per server, presumably a lot of data to be processed per second. Would RoR still be a viable platform?
I'm sorry if this question is vague, I guess I'm looking for a "RoR is fine, go at it!" kind of answer. Anything you might want to add is fine.
Thanks!
So if I were you, I would be looking into non-blocking servers like node.js, just because they are MUCH more suited to keeping many connections open for long periods of time, which is what games need to do, compared to traditional web servers.
That being said
There are 3 main things to worry about when you are scaling a web app; memory, execution speed, and io (hd and network) in that order.
For memory, things are much better then they used to be. Phusion Passenger uses copy on write to fork its workers, so the rails environment will get shared among all the workers on a given slice, which is pretty significant. There have also been huge improvements to the way ruby manages memory compared to "the dark times", if you are using 1.8.7 then you want to be using the patches that make up Ruby Enterprise Edition (the difference is like night and day). 1.9.x was pretty much a total rewrite of the runtime, so if you are using that the memory issues ruby had have already been addressed.
For execution speed, 1.8.7 is typically "fast enough" (at least after tuning garbage collection settings). 1.9.2 is actually around the same speed as python, which puts it on the faster side of interpreted languages. How important this point is completely depends on the nature of your application.
Last point is IO, which isn't really a concern of rails, but more your persistence strategy. Rubyists tend to love new things, so you will find first class support for things like redis and mongodb, with loads of people talking about using them and their wins/gotchas. I would look into mongo if I were you and see if the durability trade-offs are acceptable.
I was in java/.net before going to rails, and at the end of the day you are going to pay more for infrastructure, but the amount will be completely dwarfed by what you save in development time.
build it in Rails, host it on Heroku.com - job done. Almost infinite scaling that you don't have to worry about how it works (it just does) and it hosts a lot of highly trafficked Facebook apps so can more than handle it.
I think Ruby on Rails is a good choice for what you need. Actually, we recently created a platform for an online gaming tournament, where players and their gaming bots were playing a logic game.
We used Ruby on Rails and Sidekiq on the backend, ReactJS and WebSocket on the frontend. And it worked well for a quite massive number of players. Here is the tutorial based on what we learnt while building it: How to Write a Game Engine Using Ruby on Rails
As you said yourself, you already have the answer and you are only looking for encouraging words:). I am not RoR expert myself, but I don't think scalability is still such a great issue on this platform. I would advice you to do an architecture spike (XP terminology). Write a test with 7000 clients and method which would perform similar operations to what you intend to create. For example you might load files, render views or even just wait... The point is to test only the thing you are worried about. Good luck!
This is a bit of an impossible question to answer because in order to know whether rails is suitable for what you want to do we would need to a lot more about what you are trying to do. The best advice I can give in the absence of information is for you to check out the railslab scaling videos in order to work it out for yourself.
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'm about to start building a tumblr clone that handles multiple users (so premade clones like Gelato won't cut it) and I'm not sure which framework I'd like to build this is.
Right now, I'm only intending to build a prototype. Something I can get a dozen friends on to test the concept and grow to maybe a couple hundred users to prove the market, so I'm not worried about long term scale. My biggest concern right now is quick deployment. I'd like to get from zero to signups in as short a time as possible, with as little customization to the framework of choice as possible.
I have experience with PHP, but not Ruby. However, I don't think the learning curve would be too steep so I'm not ruling out rails. I just want the framework that is most appropriate for a system like a multi-user tumblr clone so that I can build it with as little hassle, and as quickly, as possible.
If anyone has experience with a similar project, or with these frameworks and can offer an insightful perspective, I'd be very appreciative.
Thanks for taking the time to read.
Cheers,
~Jordan Feldstein
Definitely Rails. It'd much faster to develop project like this in Rails.
As far as I saw, PHP is lightyears behind from Rails in ORMs. And Rails routing is much better than any PHP framework's as well.
I have been developing in PHP since 2000, and still have a bunch of PHP systems in production (using both CodeIgniter and CakePHP).
I have found Rails to be incredibly more efficient to develop in ... easily 50% more productivity, depending on the use-case. Faster, higher quality. Easy choice for me.
+1 for Rails.
I can't speak about Codeigniter. My general understanding echoes the above statements. Lightweight and no fully object oriented.
I have developed in CakePHP since Jan 2006, after trying to get Rails deployed on my own server and failing badly. Rails was not easy to deploy back then...at least not for me. At the time Cake was the best alternative, and still is in many ways.
Cake is a very competent framework. However, I agree with the statements that it is in many ways far "behind" Rails. Some features are not as well designed, less integrated or simplified in comparison.
A few months ago I spent a couple of day porting one of my Cake apps to Rails2. Just as an exercise. The learning curve was very shallow for someone like me (with a decent grasp of the concepts that Cake and Rails are built on). We recently started porting one of our apps at work to Rails (also from Cake) because we found that support for a lot of things that are important to us are available in Rails or Ruby but not available or as complete in Cake and PHP.
If you are unsure about switching to Ruby you might want to look at Lithium (previously CakePHP v3). It is PHP 5.3 only and still a good way from 1.0 but the community is active and generally it looks like what Cake might have been if it had been started today and not 2005.
CodeIgniter is very lightweight, which is probably to the detriment of this project if you want to code as little as possible.
CakePHP is pretty much an attempt to port Rails to PHP, so choosing between those two frameworks will depend on other factors.
One factor would be whether you want to learn Ruby or not. I have dabbled in it, and feel it is superior to PHP, but more practical concerns keep me from experimenting with it more (have to use PHP at work).
Another concern would be hosting. I use Dreamhost, and the fee is the same for PHP and Rails. However, a friend of mine just got a GoDaddy hosting account, and he actually has to pay a higher monthly fee to have a Passenger-enabled host.
I'm working on a project that is considering using Cassandra as a database. We would like to eventually migrate to Cassandra even if we use MySQL to start with, given its scalability. I know that big companies like Facebook, Digg, and recently Twitter is using Cassandra, but I don't believe any of those sites run off Rails. My question is whether or not it's feasible to use Cassandra using Ruby on Rails. Points to consider:
We heavily rely on the Authlogic gem. Would switching to Cassandra affect how it works?
Are there any mature ruby clients for Cassandra? Looking on Github it seems that fauna's client (now twitters's client) is the most mature. Has anyone had production experience with it?
Appreciate any tips.
Twitter is running rails on most of their front end. Fauna's client is actually built and released by twitter, so you can be pretty certain that it's up to date and stable on large workloads. Looking at the history of commits shows that there are frequent improvements being pushed to it, which is great.
Most likely Authlogic would need to be customized to work properly with Cassandra. In particular, it appears to provide certain methods based on named_scope and relational data.
It does appear that someone has built a plugin for DataMapper support in Authlogic: http://twitter.com/collintmiller/statuses/2064046718. You may be able to use that as a starting point for making it compatible with Cassandra.
Good luck!
I don't think starting with MySQL and then moving to Cassandra is a good idea.
Cassandra is a NoSQL solution, while MySQL is a "classic" SQL-driven database.
This means that your models would be different.
If you start with MySQL, you will have to rely on ActiveRecord for creating your models. If you then change to Cassandra, you will have to change all your models to a NoSQL-compatible middleware (such as BigRecord). This not only means changing your models, but also the controllers that use them (since their interface would be different).
This said, Cassandra and the like are supposed to be used on very demanding applications - like twitter.
The rest of web applications out there are orders of magnitude less intense - are you sure you still would need Cassandra?
PostgreSQL, and a well-designed database, is just good enough 98% of the time.
If you then change to Cassandra, you will have to change all your models to a NoSQL
This isn't true at all. If you have programmed in such a way that your MySQL db does loads of joins, then yes, you may have a problem. We avoided joins as much as we could from the beginning when we started the MySQL route. Then when we started migrating to Casandra it was fairly easy, we did so with 1 model only at first. Then say 4 models in one go. Etc. Works well. In fact, when you read the interview with twitter you'll notice they ran MySQL and Casandra in parallel for the same model for a while: http://nosql.mypopescu.com/post/407159447/cassandra-twitter-an-interview-with-ryan-king.
As to Authlogic, you can keep that part in mySQL for as long as you like, just keep it loosely coupled with your Cassandra data.
I'm researching Cassandra, MongoDB, and CouchDB right now.
One way to tell which has the most developer support, is by checking the number of watchers on the highest rated github project for each. At least as a rough estimate.
Right now it's
852 - MongoDB
http://github.com/jnunemaker/mongomapper
544 - CouchDB
http://github.com/jchris/couchrest
178 - Cassandra
http://github.com/fauna/cassandra
Although, I have to say with a bunch of high profile sites (Twitter, Digg, Reddit, etc) recently announcing that they're moving to Cassandra, this is a big vote of confidence for them.
Mongo seems to have the most and best documentation so far. Their auto-sharding is still in alpha though so how well it scales still remains to be seen I think.
I'm just starting to learn about all this stuff, so if others have insight please share.
There is also http://github.com/NZKoz/cassandra_object, which IIANM builds on top of the fauna client. "Cassandra Object provides a nice API for working with Cassandra. CassandraObjects are mostly duck-type compatible with ActiveRecord objects so most of your controller code should work ok... Use this in production only if you're looking to help out with the development, there are a bunch of rough edges right now."