Development speed - Ruby vs PHP

Hello, Readers!
As previously assured, i will write some interesting articles.
Today we are going to dispel a myth that Ruby is faster than PHP in term of development speed, learn curve and execution.

Firstly, i want to mention that Ruby is not any faster in term of development than PHP, just because native Ruby is almost the same as native PHP, except of various shortened command names, that might be confusing for new comers from other languages, but, they are completely okay once you are used to. ;-)
Most development speed related articles, let's we call them opinions - as they are, relates to RubyOnRails.
RubyOnRails is a framework, therefor i believe it is improper comparison of native PHP vs. foreign language's framework!
For above reason, i would like to really compare similar solutions in PHP and Ruby, we will take Symfony, you may compare it to Laravel, which is way easier than Symfony. Why we will compare these frameworks? Both are top languages' frameworks by popularity, both are used a lot on enterprise level.
Rails 5.1.14 vs Symfony 3.3

Application Initialization

Ruby:
ruby new app_name
PHP:
symfony new app_name

Conclusion: Tie! As you may noticed, same simple way...

API Application Initialization

Rails 5+
rails new app_name --api
Symfony 3.3+
composer create-project symfony/skeleton api

Conclusion: All the same. Few benefits to PHP when it comes to final outcome. Symfony Flex comes with all packages preconfigured which you can drop or add. Rails doesn't allow you to drop further any more than minimal installed.
Another Symfony advantage that controllers is completely optional in case of API, thank to API Platform that Symfony bases api on. Ruby will require creating models and controllers, defining routes and so on. For Symfony enough to scaffold model or create it manually, and CRUD will be available.
Additional advantage of Symfony, actually of API Platform, is that documentation automatically generated if you document models and methods according to swagger documentation. Inside documentation, also endpoints HTTP testing is generated.

Package Management

Both languages has fairly identical solutions. PHP has Composer and Ruby has Bundler.
Conclusion: Tie! Both are identical, exactly as app(not api) initialization was.

Tools

When it comes down to scaffolding, it is completely tie. Both frameworks provide identical options. Both will allow you scaffolding controllers, models, migrations, watch&debug defined routes, provide you with built-in debugging web server.
Conclusion: Tie!

Configuration and Settings

Databases: Both frameworks will require you to configure simple YAML file and provide you with various environments.
Packages: Packages configuration in rails(gems) will require from you, mostly to use initializers, luckily gems allow creator to state sample which will be moved to necessary project directory when developer uses special command. But, you'll have to deal with code. In Symfony, you will have to configure YAML, XML or INI (for you choice), but most packages with Symfony Flex will come pre-configured by default, all you will need is to adjust for your custom settings, if required. Similar to having default initializer.rb in rails.
Relations: In Rails relations are hard coded into Models. For each relation, you state the relation in both models. For example, if we have model X relates to model Y as one-to-many. You will define following way:

 
class X < ActiveModel do
  belongs_to: :Y
end

class Y < ActiveModel do
  has_many: :X
end

In Symfony, the best way is to configure relations using old and known XML.
Why XML? XML is very readable and is not afraid of loosing line-break as YAML, and Annotations that Symfony allows you too. Last is spreading configuration all over the system which is NOT GOOD AT ALL. Split configuration known to create messy code.
Routing: Routing in Symfony could also be done using YAML, XML or Annotations which is comments inside controllers. In Rails you will code similar configuration by coding into config/routes.rb.
Conclusion: Hard, but strongly, Symfony takes this with its solid and reliable configuration.

Architecture & Structure

Both frameworks allow you to go HMVC and do Anything you would like, however there is a few tricks.
Rails does not have clearly defined architecture to follow. Services you would create, you will probably instantiate directly or develop your own service locator and all belongings. On this note, Symfony has crazy advantage by having built-in service locator, solid configuration which allows various instantiation rules.
Database: When it comes down to database works, Ruby has Active Record and Symfony has fully featured ORM. Previous will quickly reveal its benefits and disadvantages under works with DB, as your DB load grows and you manipulate more data, it will be more noticed. Rails slows down amazingly, because every record retrieved being wrapped into a new instance of Model which in its turn will bring all the functionality coded in, inherited active record functionality, mixins, and so on. Which will cost you lots of memory and expensive run time. Symfony has advantage of using ORM, which relies on Entities, which is pretty clear classes that has setter and getters only, no inherited functionality and so on. This means that Symfony out of the box forces you to use Repositories or Interactors for manipulating data. In Rails you will have to break your head and (re-invent wheel?) most probably code PORO(plain old ruby object) which will have no inherited functionality and will speed up you application greatly, such development will cost your team a lot of time, as in additional you will need to switch queries to retrieve non standard data, then wrap it into PORO. Working with POROs will not be the same as previously used, so change existing code base to allow working with POROs. Yes, i did this in Rails... :)
Additional benefit due to ORM used, Symfony will make your code cleaner, as all the queries, etc. will be kept in Repositories. In Rails, queries will be kept in model and always be inherited to every record. If you switch to using POROs, you will probably go the Repositories way as well. Yes, did this in Rails as well.
Controllers: Technically, in Symfony you could not extend AbstractController or Controller at all and everything will work fine, as you are working with Response and Request objects, but you will not be able to access many helper methods provided by controller, and one of significant is accessing container.
Rails will bring all the base with him to controller, if you watch inheritance tree (it includes mixins as well) - 48(!) classes is mixed into one! 48!!! Waste of memory, sure, they was able to code it better way.
Conclusion: Symfony is a winner in this round by far. It provides stricter architecture, a lot better database management solution, cleaner code and less code overhaul.

I will stop here, maybe next time another extension to current article will arrive ;)

Conclusions:

All i can think, when one tells me that Rails' development speed faster than PHP is: Something inclines me that speaker probably never really developed PHP and Ruby on a professional level.
In my opinion, Rails could probably find home in small projects with 5-10 models and controllers, not much business logics and not highly load. If you will choose Rails for traffic intensive project, you'll face the ceiling and be forced to pay lots for servers or throwing lots into developments of modern/better architecture solutions just to save hundreds of bucks monthly.
The speed of development using Rails is not faster than Symfony, in best case - the same, the deeper you dive - the slower Rails development becomes.
One will not feel any difference during bootstraping the application using any of compared framework, but will face difficulties as proceeding deeper into the coding and architecture of the project, probably not that quick, in case of Rails, but sooner or later - expect it!
Lets talk slightly about learning curve. In my humble opinion, the learning curve for both is barely the same. PHP more readable, it is more like English and Ruby more like Chinese. Why Chinese? Because everything is shortened. Lets take an example of converting something to array. In PHP: (array)$var, in Rails: var.to_a
Don't take it close to heart, Rails' syntax is good and easy as PHP, but you will not really understand responsibility of a method by reading its name, as you would in PHP. Another misunderstood of developers when they face ->{} in Rails. Relax, it is just a lambda, you would write in PHP like function(){} to pass to any object. Easy, just learn it.

Thank You for visiting, specially if You managed to read till the end. I will really appreciate your opinions on subject. If you developed using both languages for at least a year+.

P.S. I have the right to compare these languages as i developed PHP for 6+ years and then gave a chance to Rails for nearly 2 years when i've done lots of interesting things and dated really great people, Thanks to RoomerTravel Ltd. for allowing me to go over from PHP to Rails for those 2 years.
Come more :P

5 Reasons Companies MUST consider upgrading to PHP7(at least)

Hello, Readers.
I am back to my blog since long time away. Now i have some free time, so i will make sure to add up interesting articles :-)
Following is AT LEAST 5 reasons that should convince you to upgrade.

1) Cut Expenses
Company will cut expenses by cutting down the memory usage, because PHP7 have implemented an optimized memory management when using lot of things, including, most usable - ARRAYS ! Lets take as an example generating 100,000 integers array and show the difference between PHP < 7 and PHP > 7.

$amount = 100000;
$beginMemory = memory_get_usage();
$array = [];
for ($i = 0; $i < $amount; $i++) {
   $array[$i] = $i;
}
$endMemory = memory_get_usage();
$memoryUsed = ceil(($endMemory - $beginMemory) / (1024*1024));
echo "memory = {$memoryUsed} MB";

In this case, depends on the machine, but mine is 64bit, so the result is following:
PHP5.6 - 14MB
PHP7 - 4MB


This argument, in my opinion, over weights any other reasons, so that i wrote it at first place.
May save companies hundreds of bucks in case application is memory intensive.
In case when developer chooses using SplFixedArray, this saving on expenses might reach X10 and even more.
If one, uses SplFixedArray for the code above, the overall memory consumption might reach as low as 2MB ! Feel the difference !

2) Easier hiring process
You would ask HOW? I will answer.
We are, as developers, usually tend to better/latest technologies, just because we understand that the old technology will leave us in the old world after for example 3 years. This leads us to think that after years working using old technologies, when we will back to job market - almost nobody will need us, because during recent years, most of companies have advanced, but we, as professionals, left behind and have to catch up...

3) Speed up your application
Literally like that. PHP7 out of the box is speeding up application by twice or triple of PHP5.6 on average.
As of writing this article, PHP7.1.10 is on market and 7.2 on its way as RC4 (next RC release on 26 October 2017 and final version will come very soon).

4) Improve code readability
PHP7 brought to us strict data typing, which bring us even more execution speeds and highly improved code readability.
Improved code readability will save development time, telling you as developer myself.

5) Security
PHP7 has better understanding that security matter and added new way algorithms to hash password and many more features that help solve security issues.

P.S. PHP 5.6 upgrading to PHP7 does not takes much, in case you don't have PHP4 mysql_* functions usage in code:) and you are not turning on strict data typing by default.
Enjoy the reading, and read more in google.
Also don't trust me wisely - benchmark youself first.