Related
So I know this has been asked before here:
How to start facebook app?
But I am banking on it being a little old and also hoping I have something slightly more specific to ask. So here goes:
I want to build a basic Facebook app, that would require a basic database, a simple front page, and obviously the ability to share/Like over the feed. Now my main concern is I want to do this quickly and easily, without having to deal with as many mundane details as I can avoid.
I was thus looking at CakePHP and Ruby on Rails as frameworks. However, I am not familiar with either of these technologies (I do have a software background, but it is mostly C/C++/Java). So which do you think would be best for me to pick up for this project that will enable me to quickly and easily just 'build' something like this for Facebook?
(Also note that I need a free hosting provider as I don't have money to finance this hobby now, so I'll need to know which hosting companies support these frameworks for free).
Any help is appreciated!
Rails, definitely, there are infinitely more and better resources available to learn from and you can get fantastic free hosting (for small scale apps, plus easily scale for cheap) on Heroku.
To get started, see:
Rails for Zombies (free)
Rails 3 Tutorial
Railscasts
I was in the same situation as you last fall, I knew a fair amount of PHP but had never worked with an MVC web framework before. I tried to learn CakePHP, struggled for a while, then thought I'd spend just one weekend giving Rails a chance. I had never touched Ruby before, but I was so curious about Rails that I picked up a copy of Beginning Rails 3, and I figured I would just take one weekend and see how hard it was to learn some basic Ruby and get an idea for how Rails works.
I thought going into that weekend that there was really no way learning a whole new language could be worth it, even if the framework suited me better. I'm so, so glad I gave it a chance. Ruby is awesome, the community behind it is phenomenal, and the amount of documentation, screencasts, tutorials, etc. are out of this world. Ruby is also a lot of fun to work with, and very easy to learn. Try for yourself and see what you think.
Rails is definitely the way to go (vs CakePHP at least).
The answers so far only scratch the surface!
CakePHP is to PHP what Rails is to Ruby. From the onset, CakePHP was developed to mimic the "Rails" way on things, and has done really well so far; but if you're starting from scratch; you need to remember you have to:
Set up a development environment, which in turn involves
Install the language (PHP / Ruby) and Database (MySQL?)
Learning some basic server configuration(s)
Choosing which one is right for you, and setting it up (Apache, Nginx, Passenger etc)
Get the framework up and running
Learn the underlying language
Learn the framework
Learn the Facebook API, and their developer guidelines
Actually Build the application
Test it, debug and submit for approval
Launch it
Having developed in both CakePHP and RoR - if you're coming with no web development background and you're looking to start; dive in with either. Honestly, it'll be the same learning curve for you! You will find the setup, learning, development and deployment easier in CakePHP - PHP is one of the most popular languages. If you want to learn a language and framework also to improve your skills as a programmer and developer, then you want RoR - it's got strict conventions that do twist your mind but once you get the hang of it, there's no looking back (and these are the same conventions that CakePHP is trying to bring to the PHP world!).
The official documentation for both is excellent, they have amazing (and very active!) communities where even the silliest question is answered. There are also excellent (free) hosting platforms available, that make use of Git and make deployment a snap (PHPFog and Heroku).
It might be worth mentioning that RoR is considered the new boy on the scene, the trendy framework thats bringing with it a lot of rapid changes in development methodologies, and that RoR developers also are in very high demand.
Also - considering the simplicity of the App - have you considered using Sinatra (a very minimal framework for Ruby)? You may find that the easiest, and it'll be an excellent stepping stone if you later wanted to get into Ruby on Rails.
OK, this thread is about 1 1/2 years old by the time I write this. But wanted to add something to the discussion for anyone finding this, as I did doing a search on RoR vs CakePHP.
As of this date, and during the last 12 months, RoR is trending about 3 times what CakePHP is, according to Google Trends. Now, this is just RoR vs CakePHP.
When I add Facebook into the mix, RoR/Facebook is still about 3 times CakePHP/Facebook, but if you look at the last 3 months, CakePHP/Facebook drops to zero. Link.
Right now, the trending languages for Facebook apps are C, Java, & C++. Link.
If you are more familiar with C/C++ then you will most likely find the learning curve for PHP a lot less steep : )
For something like a Facebook app and already knowing C, I would look into CakePHP. If you have time in the future look into RoR as it is an amazing platform.
Don't get me wrong, I love CakePHP. But if you don't have a background in web programming (PHP in particular), even CakePHP can take quite some time to be familiar with. RoR would be at the same learning curve, I suppose.
Besides, to deal with facebook API, you'll have to interact with it at 'base' level (by which I mean, the framework can't help you much with it). So to "quickly and easily just 'build' something like this for Facebook?" I don't think it's quite possible.
Anyway, if you still want to do it, CakePHP would be easier for you because PHP syntax would be similar to C and Java. But Ruby is an interesting and unique language if you have the time to spend on it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
If I learn Sinatra or Padrino, does that help me with Ruby on Rails?
I assume that for all of these I need to get a better understanding of Ruby itself, but does (say) Padrino translate directly into skills I would use in Ruby on Rails or is it indirect?
I am a PHP programmer, but, as I have used PHP frameworks which are clones of Ruby on Rails, I am finding it not too difficult.
You can't skip the step to learn Ruby, because every Ruby MVC extend it, and if you have to do some important customization/optimization you'll do it in Ruby.
My advice is to learn a Ruby base (variables, blocks, modules, hashes,..), use Ruby on Rails in the real world, learn Rack and then choose the best "pieces" of the Ruby world that suit your needs.
This might be a more controversial opinion, and I'll admit to being new to both still, but as someone who just spent a week on Sinatra and then moved on to Rails, I would recommend going straight for Rails. Initially, it will seem like there's a lot more to learn about Rails, but if you're going to write something moderately complex, you're going to move to Rails eventually, and it's less work 'unlearning' from Rails what you need to write a Sinatra app than it is to relearn things to do it the Rails way. You save yourself the pain of having to shift gears when it turns out that your project you started in Sinatra was best done in Rails after all (which happened to me).
This does mean it's going to take a little longer to get up to speed on Rails. I recommend starting with Michael Hartl's tutorial and the official guides. However, my advice is specifically geared towards existing developers who already know how to develop web apps and are more likely to have more complex projects in mind than beginners. Someone brand new to web app design may very well appreciate the immediate gratification that building a basic Sinatra app will offer, but that doesn't seem to be you.
Experienced developers will probably argue that you can definitely write 'moderately complex' apps in Sinatra too, and they will be right. I think Sinatra's strengths are in being a fallback for experienced developers who want to knock out a quick app without Rails 'overhead', and not as an introduction to Ruby/Rails based web app development.
Padrino is based on Sinatra, which in turns is based on Rack which is also the same ruby web server interface implemented in Rails. So yes, they have some common features, but no, learning Sinatra won't help you much in learning Rails if you don't learn Ruby before.
If you have used web frameworks before you are already familiar with MVC, templates and models. What you need to know now is the framework specific syntax so you need to work directly with the framework you want to learn.
Rails and Sinatra shares some common principles and habits which belongs to the Ruby ecosystem. But you would need to learn Ruby before in order to better appreciate these frameworks.
Don't assume the "learning Ruby" step to be an optional task.
Rails => Ruby => Sinatra => Rails
I did Rails + Bootstrap first, and while my deliverable at the end was really glossy, my ability to customize and upgrade was really shaky and REALLY REALLY slow. From there I moved onto the Ruby language syntax, some _why books and whatnot, and that sort of had me making sense of some things that initially just appeared as "magic bullets." After some time spent with Ruby I picked around at Sinatra, which was really fun. Sinatra made it possible to push a local server with a fully functioning webpage with a single page of code! It made it possible for me to experiment with databases and datamapper in a very intimate way. Currently I've shifted back to Rails, and things like scaffolding, model generation, controller generation, etc... these things are magic in a totally different way now. So I say:
Rails
Ruby Syntax
Sinatra
Rails
Rinse, Repeat...
I don't think Rails is a guaranteed final destination for a web developer using Ruby (though it is likely (: ). I worked with a software company that used Ruby and not rails for the web application. I started down a similar path as you (PHP). I wanted to develop using Ruby and began looking at Rails but found it pretty daunting. I started learning basic Ruby stuff and early in that process I discovered Sinatra. I loved it from the start. Learning using Sinatra allowed me to piece by piece add in various gems like an ORM or authentication and see how they worked individually. There are way less "moving parts" in an early stage app using Sinatra and for me that was preferred. I interact with a lot of Rails guys and from all I gather from our conversations I think it would be quite painless for me to develop a project using Rails now.
So my two cents is that for some people, learning Sinatra first may prove very helpful. But different people learn differently, so I don't think there is a one size fits all answer to this question.
Lean Sinatra, then Rails.
Rails has a lot of built in "magic" which means you don't really need to know HOW anything is working to get it up and running.
Next, when you decided to pick up Rails, you will have a better understanding of what is actually happening. The "magic" still exists; you just have a better understanding of how its doing its thing. This way if something breaks, you'll have a better understanding of how to fix it.
Good luck!
If you want to learn rails a good way is to follow the road map that is mapped out on this blog post. It is what I used and it was a great start. Obviously if you already know PHP there are steps that you can most likely skip, but overall it is a really good approach to taking little steps towards learning rails http://techiferous.com/2010/07/roadmap-for-learning-rails/
Just wanted to add my opinion that yes, learning Sinatra or Padrino will definitely help you learn Rails. In the sense that it will make the transition from PHP (or whatever) to Rails a lot less daunting. As wuliwong said, Sinatra and Padrino are way less complex than Rails. In fact, Rails is too complex for its own good in my personal opinion, routing in Rails is a bit of a nightmare, but let's not get sidetracked.
Also, while it is true that you cannot learn Rails without learning Ruby, there is no reason whatsoever why you couldn't learn Ruby as you lear Rails (or Sinatra/Padrino), it's a fun way to learn the language.
I started with Rails directly, with no knowledge of Ruby at all, coming from PHP. Did a lot of the tutorials out there, bought a few books and kept slogging on. After about 7 months of work with Rails I moved to Padrino to build an API and immediately loved its simplicity compared to Rails.
Once you get good, Rails has a lot of high-end magic that is awesome, but while you're starting out it's very overwhelming. Sinatra/Padrino allow you to start out smaller, easier and keep adding.
Good luck!
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a boss who is convinced learning Rails is too steep a learning curve and not cost effective from a labor standpoint when straight Ruby running as a CGI app on Apache is available. He is proposing, for our rewrite, that we use straight Ruby w/ no framework rather than Rails (or Merb, Sinatra, etc.) I believe in my heart that this is a bad idea but I'm having trouble putting my case into words. Some ideas I've come up with so far:
Rails promotes better code reuse and better separation of concerns via MVC
A shop running rails will look more attractive to the qualified job seeker, since Rails looks better on his/her resume, is more fun to work with, etc.
(I may be wrong on this one) Rails will have better performance on Passenger because Passenger automatically pools connections to the database where as a handrolled CGI app would have to manage that itself or not at all resulting in worse performance.
Rails is a proven technology, at least certainly more than a handrolled CGI framework
Are there any reasons I'm missing or wrong about? Are there valid tradeoffs I'm not aware of?
There are occasionally good reasons for a company to roll their own framework instead of using a standard Rack-compliant framework. But "Rails has too steep a learning curve" is not one of them.
Doing it brute-force is actually more complex, rather than less. If your boss is really worried about learning curve, he should use the standard framework that has documentation and articles and screencasts and entire hosting companies dedicated to it.
Besides, Rails is dead easy to develop for. I've taught one-day workshops on Rails, and even people who have never programmed before have a working, deployed app by the end of the day. Experienced developers have an even easier time of it.
If your boss doesn't understand Rails, and rather than figure it out, he's giving you this line about Ruby over CGI...be careful. Technology left him behind 15 years ago, and he's no longer qualified to make technical decisions.
He should be moved into marketing without delay.
Does your boss have any reasons for his conviction? Other than "a feeling"? What are his real concerns - you won't have much success in changing his mind until you have worked out what his underlying concerns are. Don't be surprised if they turn out to be substantially different to what he's currently saying. He may have an irrational fear of Danes, for example.
Do you have any concrete reasons for disagreeing?
As a boss, I wouldn't be too swayed by the reasons you list so far: good design/coding practices don't need a framework, recruitment isn't your concern, performance optimisation? Don't do it? How more proven than CGI? (He might say, not me: I drink the Rails Kool-aid every day).
Is he technical in a current sense? I mean, will he be involved in coding the rewrite? If so, might he be open to a challenge? Pick a subset of features, buildable in a day or two and try it both ways. If he's not technical, why does he think your opinion is less valid than his?
If he's concerned from a cost/effort perspective, why does he believe that writing less code (and getting thousands of lines of useful, tested framework code for free) is more costly and/or more effortful than otherwise?
Someone else has already mentioned "managing up" - I suggest Googling for resources on ways to work on this.
Are there other members of a team involved? How do they feel?
Martin Fowler famously (in the Agile world at least) said something like "if your organization is not doing what you think it should, you should change your organization". There are at least two ways to read that...
I think a potentially great idea would be to use parts of RoR(Cough ActiveRecord) and roll your own stuff if it simplifies things... I'm not a framework kinda guy, I prefer libraries and a certain degree of code abstraction, which is why I could never be mistaken for a RoR fanboy... but I think getting him to use certain parts of rails, might turn into using all of rails.
Only other point I would like to make is that MVC isn't rails only and if you rolled your own then you could very easily follow that design pattern... besides rolling your own can have benefits... for one thing, you'll know exactly what everything does and how it works, self rolled would mean a leaner system, that you can modify more easily...
My final answer is meet in the middle... Ruby is EXTREMELY powerful in the hands of creative programmers... in fact, I'm in the process of re-rolling my 2 months of rapid "throw-together" php/jquery prototype into a erb/jquery site...
--Thinking out loud--
Not trying to crap on Ruby on Rails... but Rails are what trains go on... and trains do go fast... but they only go where the tracks take you. I'm more in favor of a "Ruby off Road" environment. Less speed, More control.
Using Ruby on Rails versus just Ruby is the difference between buying an automobile and welding a unicycle out of a single tire: both will get you where you are going.
At heart though, I think this is less a technological issue and more an issue of "managing up" as the decision NOT to use Rails is so laughably bad at this point as to be nonsensical.
I think you have two options:
Sort out a way to make it seem as if using Rails was your bosses idea all along. You might say something like: "Boss, I've heard what you've said and so instead of using full blown Rails, I'm just going to use it as a basic framework and do most of the work in straight Ruby."
Take the initiative to do a prototype of the development over a weekend, give your boss something provable that says: "This is clearly the way to go".
Good luck.
It's not a very steep learning curve. You might want to ask him to walk through a tutorial before making a decision.
Also, a big advantage is that RoR is a pretty popular system right now. Installing plugins is trivial, there are many deployment options already figured out--basically a lot of the work that isn't directly "Programming" will probably be easier.
And active record--it's so useful that it's difficult to imagine doing a web/database app without it any more.
I'm in the preliminary stages of designing a new web application, and have yet to begin any sort of implementation. The application models a fairly complex domain, and I'd feel more comfortable using tools such as the ruby DataMapper ORM (having using NHibernate in the .net world) than Rails Active Record. I also prefer jquery over prototype. All of these considerations of course point to using Merb, yet I'm aware that Merb is being merged into Rails for version 3 and will no longer exist as a distinct framework.
Is there any sense in starting work on the implementation of the application now given the fairly profound changes coming to rails? I'd really like to know if it would be worth starting development in Merb now and then porting it to Rails, but I've yet to find anything suggesting how difficult this may be. Another approach would be to start work on the domain now in Rails, and only give consideration to the ORM and frontend once v3 is released.
In essence, I'd like to know how portable a Merb app is going to be to Rails 3, but am aware that it may be too early for anyone other than the core developers to know this.
Any thoughts would be greatly appreciated. Thanks :)
-------------- Edit ---------------
Yehuda Katz, lead developer of the Merb project has this to say on his blog:
The plan is to start working on Rails immediately, and to continue fixing bugs and resolving other major issues in Merb in the interim. We will also release versions of Merb specifically designed to help ease the transition to Rails 3.
In particular, we will do Merb releases with deprecation notices and other transitional mechanisms to assist developers in tracking down the changes that will come between Merb 1.x and Rails 3. Expect a number of interim releases that get incrementally closer to Rails 3, and expect parts of Merb (most notably the helpers) to be ported to run on Rails 3 in order to further reduce friction.
To be perfectly clear: we are not abandoning the Merb project. There are many production applications running on Merb that are relying on both timely bug fixes and a clear path to the future. If you’re using Merb today, continue using Merb. If you’re considering using Merb for a project because it works better for your needs, use Merb. You will not be left in the cold and we’re going to do everything to make sure that your applications don’t get stuck in the past.
If you’ve already learned Merb, we will be working hard to make sure that you can parlay that knowledge into Rails 3. At Engine Yard, we fully intend to continue using Merb for our internal apps until Rails 3 is out, but we will be using those (non-trivial) applications to be sure the experience is smooth for everyone. There will be no huge jumps and you will not need to rewrite your application from scratch.
It's never a good time to start a complex application on a framework, really. It seems like there's always a major upgrade coming up or some other competing framework that may be a better bet. If you're having more success with Merb, stick with that right now and develop your project without fear! Both the Rails and Merb communities are going to have to cope with the merging of the projects with the release of Rails 3, but that's going to be awhile.
The project merge doesn't mean that Merb will be going away, however. Yehuda Katz will stop being the lead developer, but someone will take over the project. At the minimum, you can expect security patches and bug fixes for a few years, as long as you follow the official Merb developers' repository. Likely, after the Rails 3 release, you'll find great walk-throughs on upgrading your Rails 2.x/Merb 1.x application to Rails 3.