I have learned the language itself as well as html/css/javascript. But with no database knowledge and (a bit)network knowledge. When I read the Pragmatic book on ROR, I found it confusing at the very beginning where they creates a project and setting up databases and models. Should I learn some database(and network knowledge)knowledge first in order to fully understanding the code and to fully grasp rails? If so, points out some book suited for these subject. Thanks in advance.
sorry for my bad english..
Unless you're doing network specific stuff, all you need to know concerning networking is a basic understanding of how the HTTP protocol works.
Models have nothing to do with databases per se, they're just regular classes in your language, that happen to map to a database table in Object Relational Mapping (ORM) type frameworks such as Rails.
You can view them as the gateway to your database.
The database you'll be using is most likely a relational database. You don't need to know much about the theory, but you can get a very basic overview on wikipedia.
Probably the thing you'd need the most is a basic understanding of SQL, although the point of an ORM is to abstract that SQL away. You'll see glimpse of it when you look at the log file where you see the actual database queries. And when you get to more complicated, specific stuff, you might need some SQL.
In any case, you'll need general knowledge about databases and SQL in pretty much any type of development.
The short answer is YES. Even though ActiveRecord abstracts away much of the dirty work with the database, it is still important to understand what is going on. It will be useful, sometimes vital, when debugging, deploying, and/or maintaining.
You almost certainly will need some general understanding of SQL to work with RoR (and as others have said, probably for programming itself).
I'm a fan of the book Simple SQL. It covers SQL generically, as much as it can. That is, it goes over the basics of SQL itself rather than the details of one or the other SQL implementation. Also, the majority of the examples are web related which should fit you well.
I'd agree that a basic (at least) understanding of SQL is essential when doing any sort of database work. I found the "Sams Teach Yourself SQL in 24 Hours" book helpful when i first started dipping into database work. It covers pretty much everything you need to get you started.
My advice would be to pick a DB (MySQL, Sqlite, MsSQL etc.), learn some of the basics for that particular DB (i found it useful to know how to create new users and set permissions), learn some generic SQL and really get to know what ActiveRecord can and can't do.
Hope this helps a little.
What is really important is to understand the concept of MVC (model view controller)
I recommend you reading this getting started guide
RailsGuides in general are really helpful and more condensed than the book. You might prefer it
(source: rubyonrails.org)
Related
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
I am (quite) an experienced programmer but totally new to Ruby and Ruby on Rails.
RoR looks great to get working quickly, specially the automatic screen generation for CRUD operations.
It really it gets you productive quickly.
The questions is with the last 20% of the work, when I must finish my application. Won't RoR conventions stand in my way? Because not every database table must be available for all users, and not all users can edit all columns and/or all rows, and the views must be adapted to my site's look and feel, etc.
I understand RoR has been used successfully in live sites, but how exactly do you gain enough speed in RoR to escape gravity after the first phase has been burned out.
I don't think scaffolding gets you 80% there. Scaffolding is nice in that it shows you how the pieces of Rails fit together, but I wouldn't build my application off of scaffolding code. Now that you've been impressed by scaffolding it's best that you forget all about it. :)
Where Rails really shines in my mind is database migrations, the awesomeness of how dynamic ActiveRecord is, and the plugin ecosystem.
There's a lot to learn when deciding to go with Rails. You have a new language, new framework, and new plugins - but if you take the time to learn those things you can be very productive with Rails.
I've been doing ruby on rails for quite sometime. The 80/20 problem is not unique for rails. It applies generally to the entire world. I'm also not aware of any framework that can just do business logic for you.
To answer your specific questions. Conventions will not stand in your way while doing the 20%. Instead, conventions will help you to get through that 20% quicker.
Personally, for user authentication, I use Authlogic. For user authorization, I use Lockdown or Authorization plugin depending on customer need.
I also use inherited_resource in most of my projects to simplify controller code. This is another power of convention.
To increase speed of development, you will not only need to know Rails, but rails gems/plugins that does the right things for you, so you don't have to reinvent the wheels again. Also, knowing Ruby language is a must for quickly develop beyond the 80%.
Ruby Toolbox provides some of the most popular gems and plugins used in typical rails projects targeted at specific domains. You can look through the relevant categories and know what most people use. (And it's probably a good idea to use popular, well maintained gems)
TDD/BDD style development will also help you to speed up in the long run.
Lastly, a warning: If you stray away from rails convention, you will have a painful time in general.
P.S. I used Merb before. My feeling is that conventions helps you in merb, but you won't get too much penalty for not following them in merb. However, my experience with Rails is that if you decide not to follow rails convention while developing rails app, it will come back to bite you in one way or another! So think twice when you really attempted to stray away from rails conventions... (This is from my own experience, and of course subjective, but you can think of it as a warning...)
Won't RoR conventions stand in my way?
Because not every database table must
be available for all users, and not
all users can edit all columns and/or
all rows, and the views must be
adapted to my site's look and feel,
etc.
This is a bit of a non-sequitur. Rails is a framework that has been lifted from real world applications. Those applications had to deal with all those issues also, as well as others you may not have thought of yet. Generally, the conventions make life easier once you learn them.
Another point is that the conventions are merely conventions. You don't have to follow them. You do not even have to use RoR for everything, though I've yet to find a case where I didn't/couldn't, I do generally try to push as much into the DB or cache layers as possible.
I don't believe that you'll ever have a serious problem with Rails conventions. Just stick with the conventions and trust the RoR system. The people behind Rails put a lot of effort into these conventions to support 99% of the common usage scenarios.
If you really need to do something outside the conventions it will eventually get complicated quite fast. However, you are not alone. There are a lots of excellent resources on the net to get help (for example the StackOverflow community).
To sum it up:
Stick with the conventions whenever possible (excellent resource to get started: Rails Guides.
Don't reinvent the wheel. Look for Rails plugins and Ruby Gems instead (don't forget GitHub).
Consult the StackOverflow community if you need something out of the ordinary.
Test all the f***ing time (just for fun).
The question is in the title.
It doesn't favor one over the other at all. It's just common to use LINQ to SQL examples because they are simpler to setup and deploy, so it's easier to digest the sample code without getting distracted by something which deserves its own learning path.
I agree that it does not favor one over the other. I always assumed that Linq to SQL tended to be used in examples because it was released about a year earlier. Therefore, book writers were more familiar with Linq to SQL and/or felt it was more stable.
I agree with Rex in that it makes more sense, when giving a tutorial about ASP.NET MVC, to keep other technology decisions simple. Since either DAL implementation can be used, it is easiest to teach MVC by using Linq to SQL (the simpler of the two). Linq to SQL is also widely considered to be more light-weight.
I must admit, it would be nice to have more open-source examples of projects using ASP.NET MVC along with Entity Framework. I can tell you that it works fine, because I am using it on one project. However, it can be a bit more difficult to figure out some of the ideosyncrasies. Here is another question that shows some links to examples.
I think this tendency to use the path of least resistance in example is a diservice to new developers. How many times have you seen an example, with the caveat that it is not production worthy code, with no reason as to why it is not appropriate, or good direction on how to find what is best? Personally, I appreciate longer examples that actually lead me to discover how something should be used are more helpful.
In this particular case, using Linq to Entities would be much more useful, as it is seemingly the future.
In my opinion, it doesn't favor it. It's what you see in most examples, because Linq to Sql is the fastest way to get examples up and running. Rails follows the same convention of many examples using features (scaffolding for example) that you would rarely see used in a production site.
As all the other posters have said - L2S samples are just a lot easier to put together hence you'll see them quoted more. In reality your MVC models may not use L2S directly - they could be hooking up to a separate services tier or some data transfer objects exposed by another system entirely.
Duplicate: Django or Ruby-On-Rails?
I have been reading on Ruby on Rails, and it seems like on some threads, some users like Django a lot too?
Can someone who have used both give some insight about using them, such as
ease of use
productivity
fun factor
deployment issues
or any other framework you'd highly recommend?
Both are excellent frameworks. Though, I've found Rails to be more suited for the agile developer. For the most part, you'll run some generators to get the files you need as placeholders for your code. Things will work right away, and you just build up from these conventions. It's really flexible and has a large community, lots of innovation and interesting practices are being put into Rails. It's development cycle seems faster paced than Django.
After only touching the surface with Django, it has some interesting differences. As far as I know, you don't get the schema migrations like Rails has out of the box. But you get an extremely simple CRUD mechanism for your models with the extensible admin interface, which is great for testing/managing content. The entire project is documented really well, from the Django Book to the vast amount of information on docs.djangoproject.com.
I personally prefer the Rails way of doing things. But honestly, you need to try them both to see what works for you, and since we're talking about two very good, yet totally different frameworks, it's a tough decision to make either way. So, if you already know Ruby or Python well enough, start with what you know and just go from there. Once you understand how one works, you'll be able to evaluate the smaller differences yourself. Hope that helps.
I'm a PHP developer who knows a little bit of Ruby. I want to learn Ruby on Rails, but most of the resources I've come across treat RoR functionality as "magic" -- i.e., it has a certain internal consistency, but don't bother asking how it works in terms of Ruby, MySQL, etc.
Anyway, I want a deep understanding of how RoR works, the design decisions that went into building it, etc. In particular I'm interested in ActiveRecord, but really I'm looking for the whole package.
Any books / sites / advice welcome.
The books "Agile Web Development with Rails" and "The Rails Way" are both pretty good. "Pro Active Record" goes really in depth for Active Record, but doesn't touch on too much else. The podcast Railscasts sometimes just uses the magic, but sometimes it explains what is really going on. Various blogs such as Art of Mission can get into what your looking for.
Additionally, using the ruby-debug gem gives you a much better understanding of what is going on - you can step into what is running behind the scenes.
There are two areas here that can be examined separately:
General concepts (which include design patterns, general attitude principles like DRY and CoC or even agility etc.) since they are the principles behind many design decisions in Rails. Any of these concepts can be studied independently of Rails (since they are general programming concepts). It's good to have at least some understanding of these before digging any deeper. There are many sources about such general principles all over the net (aforementioned Martin Fowler's site is one of the better sources for grasping such concepts).
The way Rails implements these concepts into its corpus. There are, again, two things to have in mind here. Since Rails heavily exploits features of its mother language, it's crucial to understand Ruby's peculiarities (such as mixins and plenty of Ruby's dynamic features). The last thing to understand is how Rails uses these features, ie. how it's broken down into classes and modules, how many of its features are dynamically created on the run and so on. For this purpose, I highly recommend book Ruby for Rails from David A. Black (which is exactly about Ruby, its peculiarities and the way Rails uses them). While this book might be a bit out of date, I think it's still invaluable in its content.
If you really want to know how it works, you can just look at the source code. The online API docs let you see the source code of every method right in the documentation page.
ActiveRecord in Rails is based on Martin Fowler's Active Record pattern. It's basically an ORM (object-relational mapper). It's not even really that sophisticated as far as ORMs go. Java Persistence with Hibernate has a good overview of common ORM concepts.
This one might fit here well too -> http://railsforphp.com/
This is sort of a tangential answer to your question, but I, too, came from PHP development over to Ruby/Rails dev, and it was a big transition for me. As PHP devs, we're used to getting into the nitty-gritty, to to speak, and not being prevented from looking under the hood.
By design, Rails is a black box. You're supposed to learn Rails, almost as a language itself. It's a new way of thinking of web dev, especially from a PHP dev's perspective, though this idea is not uncommon to programming in general.
Not bothering to look under the hood may be the best way to start doing things "the Rails way."
Jamis Buck has a nice series of "Under the Hood" articles on his blog that cover some aspects of Rails' internals.
The "magic" in Rails involves method_missing and the concept of metaprogramming. Dave Thomas of The Pragmatic Programmers created a set of screencasts on metaprogramming Ruby.
PHP has a somewhat-equivalent function called __call, and PHP 5.3 introduced __callstatic. You might take a look at those, as well as search Google for "php metaprogramming", for some reading material on implementing Rails-like behavior in PHP.
I found this site a good starting reference:
http://www.tutorialspoint.com/ruby-on-rails-2.1/index.htm
It assumes MySQL in its examples.
I am sure you can find heaps and heaps by just googling for "ruby on rails tutorials", though.
ruby metaprogramming magic in rails: look at books by Rappin "Professional Rails" and Ediger "Advanced Rails", in addition to Black "Ruby for Rails" mentioned above
Naming conventions are important:
http://rails.wincent.com/wiki/Rails_conventions
http://www.softiesonrails.com/2007/10/18/ruby-101-naming-conventions
If you really want to understand Rails, read the source for the bit of Rails that you want.
/Library/Ruby/Gems/1.8/gems/ on OSX or freeze rails and have access to it in your RAILS_ROOT/vendor/ directory