As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I almost never hear the word CakePHP without hearing the word Rails shortly afterwards. Are these two frameworks mainly similar based on how they adhere to the MVC model or do they have other significant similarities/differences?
One of the main attractions of Rails for me is how easy it is to do Ajax. Would that also be true of CakePHP?
CakePHP is like a cheap, bastardized ripoff of Rails. It tries to be like Rails without doing any of the stuff that makes Rails great. It kinda feels similar, I guess.
CakePHP has an Ajax helper that does something similar to the Ajax-related helper methods in Rails, so yes, in some way, it's also true.
But CakePHP is really an exercise in futility: its authors wrote it so they wouldn't have to learn Ruby, even though learning Ruby and Rails together is probably easier than figuring out the monstrous mess that is CakePHP.
(This, coming from somebody who does CakePHP at his day job.)
Since y'all asked, my biggest complaint about CakePHP is how it manages to totally butcher the conveniences of object-oriented programming: sure, it implements the Active Record pattern just as much as Rails does, but it makes you pass around data structures.
I feel like any logical person would implement an ORM using faulting and dynamic loading of properties in to objects, which is exactly what ActiveRecord (the Rails library) does. The whole idea of setting a member variable called $recursive to determine which relationships to load is just plain flawed.
Being based on PHP is pretty fatal, too; you can't do anything with global state, you have to depend on mod_rewrite, you pay the startup penalty on every request. Sure, there's optimizations for any environment you're using, but still. People say Ruby is slow, but my own Rails apps run faster than their CakePHP equivalents, last I checked. I admit to being without data on this.
Worst of all, the bugs in CakePHP just about kill it for me. I could tell any number of stories about
the time we spent two days figuring out why CakePHP refused to connect to the right database host
the time half of our pages went blank because of the memory ceiling from using too many components
the amount of code that lives in our AppController because every component load costs several megabytes of memory
the black art of massaging data structures to make XML output work correctly
how we traced down the blank <javascript> tag that shows up at the end of every page
Cake is laid out much like Rails and obviously takes a lot of inspiration & ideas from it. Cake is a nice introduction to MVC frameworks and rails seems pretty straightforward coming from cake experience.
Ajax is super easy with Cake using the JS helper. In fact everything is super easy. Its a great framework, especially for distributed apps (eg cms's) or any other situation where the ease of hosting a php app is a benefit.
I would see the main advantages of rails being Ruby (and therefore the better OO implementation of rails etc) and the community. Gems (much fewer / less comprehensive cake plugins), training materials online, books (eloquent ruby anyone?) meetup groups etc.
I haven't worked with CakePHP, but my impression of it isn't too good. If you're after a Railslike framework for PHP, I think you may be better off looking into Symfony. It's probably a bit more complicated to get started with, but the whole project seems much better organised than CakePHP.
Of course, take with a grain of salt, since these things are quite subjective.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have heard a lot about PHP frameworks like ZEND, CodeIgniter,CakePhp etc and i am also well aware of some advantages of using it i.e. increased productivity,reduced errors etc but doesn't php framework make coding a complex process ? Doesn't coding without framework provides more flexibility ? Some people say you don't need any additional framework, as PHP is itself a framework.
So why there is so much usage of PHP framework ? Are frameworks really necessary in PHP?
This is a broad question and I think an important one. I am in the camp of NOT using frameworks unless absolutely necessary. The question is, when is it necessary?
First off, the thing that I think gave me this strange, allergic reaction to frameworks is that inexperienced coders want to use them for EVERYTHING, even tiny sites.... and it's bizarre. Maybe its through some need to make their resumes bigger by saying they've used codeigniter- but in my experience that doesn't make a damn bit of a difference. Hiring managers want SKILLSETS, not somebody that can read API documentation- which anyone can do. If you have working knowledge about program architecture and OOP principles, you're hired. If you don't, but you're a codeigniter ninja, .... eeehhhh.... ok?
Frameworks have their uses but I think when your mom wants to make a website for her bake sale then you can just slap a page together using a much lighter weight system. I don't sit in the camp of belief that you should include code "in case you need it". Over time, I have developed my own framework that is absolutely tiny, which is why every single web site or application I have ever built has ranked in the top 2% (though usually top 1%) of page load times in the world by google.
This is not to say they are bad- just don't go running off to use a framework because you want to put it on your resume- you're actually shooting yourself in the foot in the long run. Why? Because you won't spend time using the language itself, you'll spend time using the language of the framework. Take jQuery for instance- I avoided it for YEARS because it wasn't JAVASCRIPT. People scoffed at it- but now, when I go to a technical interview and I get asked (inevitably): "What is your experience level with jQuery", and I say "not much", and they for a second look surprised, but then I follow it up with "but I just wrote dependency injection via inversion of control in native JS yesterday"- I get hired ON THE SPOT.
Frameworks are great. Just ask yourself if you really need them. Particularly the question is: are the benefits of coding it yourself outweighed by the time benefits (don't forget about the learning curve of the platform) of the framework or not? On the one hand (non-framework approach), you learn a lot, and perhaps you take more time because you're working out your own kinks- but you learned a ton about the language itself (PHP in this case). On the other hand, you learned a new framework and maybe got a site up quicker that most likely is slower.
Wordpress is a great example of an overused framework in my opinion. Back in my freelancing days I used to take on gigs that needed me to "revamp a wordpress site"- only to find a site that could barely load because somebody plugged in every plugin they could find and made what was a stupid simple site into a tank with ungreased treads. It's OVERKILL in that case.
With my experience in CTO and Tech Lead positions, when somebody puts Wordpress and jQuery as primary points on their resume, to me that says "I don't know a thing about OOP and how to use these languages if required" which, in the real world (and I work on huge projects like windows 8 and other projects of that magnitude) - is OFTEN the case. Microsoft expressly forbids the usage of jQuery in their metro app system for MS released products because they want to show off their system dependency free.
Other companies, however, DO use frameworks. I just got off a project using Foundation and it was AWESOME- but that's because the architect of the project fully researched the framework and we used it RIGHT. The result was a fully responsive pristine code base that went from full monitor glory down to triscuit-sized smartphone screen awesomeness.
IN SHORT:
Frameworks, when used right, can be awesome- particularly for large projects (and I'm talking enterprise large). For smaller projects they aren't necessarily bad- but when they are used without thinking about their implementations, its like using a hatchet for a scalpel.
Just my 2 cents.
Doesn't php framework make coding a complex process?
It depends what you want to do. If all you're doing is creating a basic contact form for a site that is all static HTML, then yes using a framework would make it a more complex process. On the other hand if you're building a large scale app then using a framework would not necessarily make it more complex.
Doesn't coding without framework provides more flexibility ?
This depends on the framework itself, they aren't all the same. Some frameworks such as Slim or Codeigniter are very trimmed down and don't get in the way too much and so don't really impact on flexibility, some are more complex such as Symfony2/Zend.
Some people say you don't need any additional framework, as PHP is itself a framework.
They are right, you technically don't need a framework, you can do anything with plain PHP that you can do with a framework. Frameworks have really evolved from developers personal archives of functions and helper code. PHP can be relatively low level in that it doesn't have a ready made function to do everything you need. Before frameworks, developers tended to have their own set of helper code that would be reused on many projects. Frameworks are still essentially that, except they are collaborative projects that hundreds or thousands of developers contribute to.
One other benefit of frameworks is if you have several developers, and one has developed an application and you want another developer to contribute to it or take over it, then if the developer is familiar with the framework that was used he can get up to speed on the app much quicker than if it was written in plain PHP. Without the framework, the new developer would have to decipher the previous developers system before they even start to look at adding any new functionality.
Are they necessary in PHP?
No they are not, sure it is possible to code anything without frameworks. But it's more work, this is like: Why am I using C when I can do all the same by writing assembler?
So why there is so much usage of PHP framework?
The benefits of using frameworks is, that you can use many predefined things. For example, in most PHP frameworks you can use MVC Pattern. Sure you could also build your own MVC structure with flat PHP, but that is like re-inventing the wheel everytime again. Only thing is, if you have very specific requirements, you may can/should not use a framework, but in most cases the requirements are not that specific.
The point with MVC is only one of a lot benefits. Depending on the framework you want to use, there are specific benefits.
So, it is just like you said. By using a framework you can save time, because you don't have to re-invent everything that already exists.
You can see a framwork as a tool, that helps you to develop better and faster.
Edit: Like Ayesh K mentioned in his comment, it is also a benefits, that a framework is developed by many experts, so it normally is better code, following the principle: 'Four eyes see more than two'.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
We're using ORM in PHP on our team, and I've noted in two separate projects that, even though we've specifically talked about good MVC design at length, that ORM appears to be allowing people to do DB queries from the View layer and creating difficult-to-maintain code.
I'm leaning towards the opinion that ORM makes it too easy to make queries under the covers that the programmer doesn't think about. By returning ORM objects to the view layer the programmer is essentially leaking a database connection to a layer that should not have it.
Am I thinking about ORM correctly here? If so, why is it so darn popular? If I'm not thinking about it correctly how should I address these issue?
I'd say that you're not thinking about it correctly. ORM by and of itself does not promote bad practices, at least, not in the way you're experiencing it.
ORM is a tool, just like any other framework, api or whatever, you can use it correctly or not.
It sounds more like the problem is that the developers in your team doesn't have a clear understanding of the MVC pattern. I'd start with addressing that issue first.
I think it's quite a common problem with the MVC pattern that developers tend to use the views and controllers for things that they aren't supposed to do. The reasons might be many, but whenever you work with something like this, I beleieve the problem usually starts with something similar to this thought:
"It such an simple little thing I'll just do it here instead, there's
no point doing it all over there."
Basically when trying to decouple design and business logic there will always be situations when it's easier to implement some piece that actually belongs in the business layer in the presentation layer. It mustn't mean that the developer is bad, but it might show some lack of experience or laziness. I know I've been guilty of this exact thing several times, like when developing for Android (never professionally though :)).
How about trying to figure out some sample-case that uses some of the bad practices that you've noticed and have some sort of coding-dojo where you as a team make that code nice and correctly implemented, and if you have time, show the actual benefits of having stuff where they belong. I'd strongly advice against using actual code unless you've written it yourself or the developer responsible for that code is okay with being mangled in front of other devs. But this obviously depends on the culture in your company and if the developers are interested and open for these kind of things. I personally would love having similar things at my workplace.
I don't know that having small ORM calls in the view layer is necessarily bad. For example, I might have foreach (Category::getAll() as $Category): as the loop to list categories on a page. The connection doesn't leak into the scope of the view (or at any rate it certainly shouldn't) since it is encapsulated by the ORM. I could assign the result of this call in the controller and pass the array of objects to the template (and I certainly will with more complex calls) but imo trivial cases are fine in the view.
The biggest problem with ORMs in my experience is the growth of "n+1" database query counts. Normally a one:many list on a screen can be rendered from a single query, but ORMs make it extremely convenient to use a primary loop with one table, and then to do an individual select for each instance of the secondary table. This is inefficient, but you'll only notice when your database starts to creak with the expanded number of queries it is having to deal with.
The best guard against this is to ask your developers to run a toolbar in dev mode (such as the Symfony2 toolbar, PHP Debug or similar) which shows them the number of queries required to build a screen. When trivial screens start needing more than 50 queries (or whatever ceiling you specify) then they need to refactor.
Also, it's worth choosing an ORM that has a reasonably expressive query syntax, otherwise your devs will be shirking back to "raw SQL" mode, which defeats some of the reasons of having the ORM in the first place. For the same reason - and Daniel makes this point well - offering training to your devs on using ORMs effectively is a great idea.
Doing queries from views is a bad practice. You can do it, but is better doing it through the controller via Ajax Requests or whatever you consider suitable.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Now days most of PHP web development companies use PHP frameworks or open source products for developing websites but is that a right approach? If so but what will happen to the PHP programmer skill and knowledge?
Don’t you think using approaches such as “PHP frameworks or open source modification” will kill the programmer skill over the time? Is that really worth it a website developer becomes a better PHP framework writer instead of being a better PHP programmer?
I absolutely have to disagree here. When is started programming, it was PHP and I had no clue what I did. I wrote everything myself and had no will to even look at framework. I spend way too much time in work that repeated again and again.
Frameworks are one of the most useful tools IMO (not only web frameworks)
They speed up development in lots of ways
Looking at the sources, I learnt more about good practices, design decisions, directions to think to
Taking bits and pieces of the framework and use it in other apps where the use of a framework is not possible
They help you focus more on your work (MVC, DRY, KISS, ...) instead of fiddling around with the basic
Most established frameworks have a huge user-base and are very well tested.
I think looking at other code helps you be better and more efficient over time. SO is a very good example of this.
Using a framework doesn't make you a weaker programmer, otherwise I could argue you should write you next web app in assembeler, not much fun.
A framework should be thought of more like an extention to a language, a DSL if you like. For example CakePHP is just PHP with extra cool-stuff that makes handling databases and sessions "cake" - excuse the pun.
By using a framework you take the 'yuk' out of preogramming, and allow yourself to treat data as objects, for example.
If you still feel you shouldn't use a framework, then write one, then use it! By this reasoning you should also go and rewrite the PHP libraries and interpreter, however I don't recomend it.
In my opinion, I don't think frameworks "kills the skills" at all, instead it allows skills and more creative workflows to develop, which ultimately leads to enhanced skill. Also, the understanding of how large scale applications are developed are increased with effective use of well developed frameworks, which is definitely a big plus in the end too.
It allows applications to be developed more quickly and efficiently; and the end result is what matters. If you write PHP and don't know assembly, it doesn't mean you've lost your skill - you've simply focused on a higher level of technological progress in this modern age.
I think it's important to know some of the underlying concepts, such as creating and interacting with databases, OOP, design patterns. Frameworks can introduce you to these concepts without making you learn everything at once. They also have the advantage of several thousand hours of development time already invested, a community of testers and bug fixers, etc.
Anecdotally, you hear stories of people starting with a framework and slowly replacing parts of it as they optimize sections of their site. They distill the framework's operations down to their specific requirements. You can't take this route if you aren't a strong programmer.
Frameworks allow you to do work without reinventing the wheel. And the people working on this framework are probably a lot smarter than you, and they have spent a lot more time thinking about the code.
At the end of the day, it's about getting things done. Any given individual may be more productive with a third-party framework, or without. But a framework is the conclusion of any large project, whether you end up creating it yourself or you rely on the work of others.
To work on PHP based framework, you need to be a better PHP programmer.
so, your skill level will increase and it will not decrease...to tell with an example.
We can start writing all the program in assembly language, why do we use high level language...? If you find the answer for this, then you will get the answer for this problem too. :-)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In the jungle of frameworks out there, I've come to the conclusion that I cannot simply decide on a framework without considering the type of application / site I want to create. I think I need a little help with determining this one.
This site is graphics heavy, with all of the content presented in a small <div> in the centre of the page, surrounded by graphics. The graphics around it should preferably be loaded only once.
The site will allow users to log on with their account and choose from a number of pre-made food recipes, or create their own. Then they can press a button to have the site generate a week or two of dishes.
The users will need their own control panel where they can customize stuff as wallpaper, dishes, labels etc. As well as browsing recipes, adding ingredients, and looking up which dishes they can create with the ingredients.
As mentioned, all of this data is supposed to be presented inside a square in the centre, so we need a system of jQuery panels. I was thinking of dynamically adding content to this square as needed. For example, emptying the content and adding new content to it when clicking links, etc.
We don't need any community per se; the possibility for discussion can be explored in a separate, external site.
I should mention I am more of a designer than a programmer. I get stuff pretty easily, but fear I don't have the capacity to create a framework like this from the ground up. I do know a bit of Visual Basic, but I'm not so good with C# syntax. I've never even touched PHP, but my partner has. He's also somewhat familiar with Java.
Basically, we need a framework that's easy to understand and get up and running.
I rolled my own framework based on http://kissmvc.com/. It allows you to basically do what you need in PHP but gives you an easy MVC framework to do it in. You don't have to learn the specific syntax to Zend, Cake, Code Ingiter or Kohana, all of which I played with before I found kissmvc. Based on a blog post by Rasmus, it was all the direction I needed and I love what I have now for reasons #animuson mentioned.
Rasmus' post: http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html
From what you write, I would say all "big, famous" frameworks will be able to do this fairly "easy"... So You should really define a few prototype tasks and check out a few of the frameworks. You should be able to solve this using, CakePHP, Symfony, CodeIgniter, Yii, Zend, or any other framework, so it is better to do some real testing.
You might look for a framework that has a tight integration to jquery, but this should not be a showstopper, since you should be able to implement this in almost any framework.
You might also consider footprint and execution time, and find a framework that performes well and is not too cpu heavy (read Yii or CodeIgniter for instance).
Good luck in the search
Ultimately if you want it to fit your needs you need to build your own framework, otherwise there will always be limitations. Keep in mind that there is no framework that you can simply install and tell it to do these things, you are going to need programming knowledge of how the framework works in its entirety and how to program your custom pages to work with those features. I found it easier to just build my own framework. That way I always knew exactly what everything did and if I needed something additional, I could easily add it in the correct spot without doing much thinking on it.
A framework is only the base materials and functions you need. If you're looking for something like a pre-built website such as PHP-Nuke or a forum system, you're looking for a content management system, not a framework. A framework generally comes with absolutely no pre-built pages. Might I add that some content management systems do come with their own framework and some use existing frameworks from elsewhere.
So, we basically need a framework that's easy to understand and get up and running.
well as far as the above statement is concerned you may want to have a look at cakePHP framework.
You will easily find help on cakephp framework on stackoverflow and cakephp google group. Response will be quite fast on both the sites.
You will need to go deeply through the documentation of every framework that you plan to use because with a functionality that you are planning to built would require you to study the framework quite well.
With cakephp you will be able to create CRUD (create, update, delete) operations quite easily with less effort, but for further functionalities you will have to study it's documentation and keep your cool while you learn it :-)
I have always found plain php to be all the framework I need.
PHP itself has all the features provided by the other frameworks
A superb templating engine, database access, parsing, and control logic.
The great thing is all these features implemented in a single unified component called "php".
The main problem is you need discipline to separate presentation, navigation, busines logic and database/persistence handling. You can have sql statements mixed in with your html, you can emit html directly from an sql statement in fact you have complete freedom to implement all the known anti-patterns and invent some of your own.
The "Java" and "Perl" frameworks generally provide things like request handling, template handling etc. which are missing from the basic language, but, these features are built into php. Most of what the "php" based frameworks do is force you into (a very sensible) MVC design pattern and save you a tiny bit of coding.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
Back when I was learning HTML, I loved how easy it to build pages and arrange everything just the way I wanted using tables.
Then I moved to CSS and learned that you could quickly swap designs without recoding your page. With just a few CSS changes your HTML designs could go from one theme to another and any element could become any other! With CSS I could design spans that looked like images!
Moving from HTML to CSS expanded my concept of design by implementing what I would later learn is modularizing things - just like MVC.
I am now a very competent PHP programmer who is thinking about Ruby. Most of the stuff I pull up on google is PHP vs Ruby rants which don't truly help anything. They are two different languages and take their style from different points. PHP looks like C++ strlen($string) while Ruby looks like server-side JavaScript. str.len()
I want to know the top 3 things about ruby that could really open my eyes as a programmer and justify the time I know it will take to pickup and master a new language.
Please, no mention of abstract things
like language maturity, or obvious
library's like AR which exist in both
languages.
MVC is now used in almost every web
programming language so it doesn't
count either. It is also not
sufficiant in and of it's self to
cover everything. MVCLLCC
(Model/View/Controller/Library/Locale/Cache/Config)
is more accurate.
:UPDATE:
Apparently there isn't too much new in Ruby compared to the other languages I use. Blocks appear to be nothing more than functions with a different name. procs seem to be blocks with callbacks which would be like a hooks system. MVC, AR, and everything else is already in the other languages.
However, I believe the most exciting thing I have seen is that you can open up classes at runtime and add new methods! This is a very important concept and really removes some hurdles that PHP has. No longer do you need extend child classes just to add a few methods to a parent class.
Well, you cut out a few of the things that make Ruby really fun, so I think any remaining list is going to be somewhat arbitrary. Here's why I think Ruby is nicer to work with than PHP:
Consistency: In Ruby, everything is an object -- even numbers. You call a method on an object the same way -- there aren't really any "special cases". Moreover, the standard library (and most 3rd-party libraries) have consistent naming schemes and styles. The PHP library has grown...organically, and as such, the names, use of underscores, etc., is chaotic.
Functional-style programming: Ruby borrows a lot of constructs from functional languages like Lisp. This is a pretty arbitrary reason, but I like functional programming, so having easy access to functions like the map and fold* methods from Lisp and Haskell is a plus for me. It also makes heavy use of blocks (aka "closures") which not only open up some very nice programming styles, but also allows you to write some very general code that can be used in a very specific manner, depending on your needs.
True OOP: Ruby's OO model is borrowed heavily from Smalltalk, and uses the message-passing style rather than the method-calling style. This lets you do pretty cool things like implement your own handlers for missing methods. Ruby is also dynamic in nature, and thus lets you define methods -- and even entire classes -- on the fly, at runtime. You can also "open" classes up and provide your own methods, which can save yourself the hassle of, e.g., extending the String class just to add a rot13 method.
RubyGems: RubyGems is a package manager for Ruby gems (third-party Ruby modules). It makes installing, managing, and removing third-party modules (and their dependencies) a breeze. (I threw this one in as a bonus reason.)
Lambdas (blocks).
Mixins.
Heavy use of the above two concepts in the standard library.
I would also nominate continuations (callcc), but they seem to be relatively obscure (which is a pity), and are gone in 1.9.
Top 3 things about Ruby that I enjoy:
Blocks and procs
Metaprogramming
Enumerable module (tons of awesome Array goodies)
Its hard to stop at 3 but maybe others can add more.
Best thing is try some code out for yourself. Good luck and have fun.
Here's at least one reason that applies to me (maybe you too): The way ruby handles object-oriented programming has "freed" my mind a lot in terms of how I think about coding and architecture. Everything is an object with ruby...
Ruby is fun to read and write
Blocks are even more fun
RUBY IS JUST PURE FUN
I'd say give it a try. I was once a PHP coder too and then switched to Ruby and never looked back. The only downside is the documentation which is clearly better in PHP (I would even say PHP has one of the best)
Here are the three things I really like.
I am not going to speak about the language itself but of what I like in the ruby world in general.
Tests
A lot of frameworks are available. If find them simple. Far easier than anything I have tried in JAVA.
The ruby community is very test-centric and you can find very good screencasts and tutorial to get you started.
It has changed the way I code.
Rails
I believe I started (seems so long ago :)). With Html+tables then CSS then PHP etc.
2 years ago I discovered Rails. And I really think It is an amazing framework.
From my point of view it is the best by far if you do Web Development.
I am curious so I have looked at other things like django, CakePHP, Zend etc but I have never find something as good as rails. Of course it is a matter of taste but I strongly advise you to try it.
Rails is not only an MVC. It is an easy to use MVC.
Ruby != Rails.
But Ruby gained an huge increase in popularity with Rails
Readable syntax
exit unless "restaurant".include? "aura"
You can try to take this interactive online tutorial (15 minutes) to see if you like the syntax.
Ruby is a general-purpose scripting language which has been incorporated into web design, and PHP is a language created for use in web design. (that's not a pro or con for either, merely a point of clarification)
If you already have experience scripting with using Ruby, it's easy to take the next step and incorporate it into your web design (as a corollary, it's also easier to pull Ruby code out of your web design and test it as a standalone script)
For many people/projects, the differences aren't monumental enough to warrant starting over with a new system. I'm somewhat of a Ruby evangelist but I would have to say if you already know PHP well, you will likely do better to stick with what you know. Certainly do not completely re-write a working PHP web application from scratch in Ruby without a lot of thought. This is a source of frustration for a lot of people (as you have probably read in your aforementioned rants) that can unfairly leave a bad taste in your mouth about a language or framework
Ruby is relatively new.
Therefore most tutorials using Ruby are using the latest best practices.
It does a lot of things differently to other languages, so it's a language you either love or hate. I personally am not a fan of it, and I'm sure a Ruby fan will come along soon and give a long list of advantages. And shortly after that, this question will be closed as subjective.
Ruby block is totally awesome!
You can create a DSL ontop of it and improves code readability which you can not achieve with anonymous function. One trivial example is like this:
def it(expect)
yield expect
end
it 'should do as I want it to be' do |this|
puts this
end