Question and answers notes

Composer

Question: What is Composer?
- Composer is an application-level package manager for the PHP.
Question: Why Composer is used?
- Composer provides a standard format for managing dependencies of PHP software.
- Composer installs the dependencies libraries.
- Composer provides autoload capabilities for libraries.
Question: Where composer is used?
- When we need manage the dependencies of PHP application, we can use Composer.
Question: How Composer Works?
- It works commond line.
Question: Who developed the Composer?
- Nils Adermann.
- Jordi Boggiano.
Question: What is current stable version of Composer?
- 1.2.0 / July 18, 2016.
Question: In Which language, It was writeen?
- PHP.
Question: What is offical website of Composer?
- http://getcomposer.org/
Question: What are System Requirements for compser?
- PHP 5.3.2+
- Need git, svn or hg repository depend of composer version.
Question: What is command to download the composer?

php -r "readfile('https://getcomposer.org/installer');" | php

- You need curl OR openssl enable for above command.

Question: How to install the composer?

php composer.phar install

Question: How to update the composer?

php composer.phar update

Question: How to check current version of composer?

composer -V

Question: Can I used composer standard for my new project?
- Yes, you can start.
Question: Is it open-source?
- Yes, It is open-source.
Question: Give me sample of composer file?

{
    "name": "zendframework/skeleton-application",
    "description": "Skeleton Application for ZF2",
    "license": "BSD-3-Clause",
    "keywords": [
        "framework",
        "zf2"
    ],
    "homepage": "http://framework.zend.com/",
    "require": {
        "php": ">=5.3.3",
        "zendframework/zendframework": "2.3.2"
    }
}

Difference between in_array and array_search

in_array : -Checks if a value exists in an array

Example::

 <?php
 	//syntax: in_array(search value, array , strict Boolean);
 	$name = array("Rajesh", "Sharma", "PHP", "Linux");
 	if (in_array("Rajesh", $name)) 
 	{
 		echo "Yes";
 	}
 	else
 	{
 		echo "False";
 	}
 	//Output: Yes
 ?>

array_search() :-searches an array for a given value and returns the corresponding key if successful.

search value:- will be the value to search in an array
array: will the array to search
strict Boolean: is optional.
Example:

 <?php 
 	//syntax: array_search()(search value, array , strict Boolean);
 	$name = array(0=>"Rajesh", 1=>"Sharma", 2=>"PHP", 3=>"Linux");
 	echo $key = array_search("Rajesh", $name);
 	//Output: 0
 ?>

difference between array_merge and array_combine in php

Array Merge:
- Merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one.
- If the input arrays have the same string keys, then the later value for that key will overwrite the previous one or if the arrays contain numeric keys, then the later value will not overwrite the original value and will be appended.
- Values in the input array with numeric keys will be renumbered with incrementing keys starting from zero in the result array.
```
 <?php
 	$array1 = array("color" => "red", 2, 4);
 	$array2 = array("a", "b", "color" => "green", "shape" => "trapezoid", 4);
 	$result = array_merge($array1, $array2);
 	print_r($result);
 ?>
```
- Outpull will:
```
 Array
 (
     [color] => green
     [0] => 2
     [1] => 4
     [2] => a
     [3] => b
     [shape] => trapezoid
     [4] => 4
 )
```

Array Combine:

Creates an array by using one array for keys and another for its values
example:

 <?php
 	$array1 = array("green","red","yellow");
 	$array2 = array("avocado", "apple", "banana");
 	$result = array_combine($array1, $array2);
 	print_r($result);
 ?>

Output will:

 Array
 (
     [green] => avocado
     [red] => apple
     [yellow] => banana
 )

MySQL Engines - MyISAM vs Innodb

When MyISAM tables are seen to be mostly useful?

There can be several other reasons that fit your requirement for choosing the MyISAM engine. For example reads can be faster on MyISAM vs Innodb despite what the general claims on the above two links when MyISAM table has fixed (not dynamic) row size i.e. when it uses more CHARs for example versus VARCHARs. Still there could be other reasons besides this why you choose or have chosen MyISAM over Innodb. Another reason why you may have chosen MyISAM over Innodb is perhaps due to the fact that Innodb must perform additional checks owing to its ACID compliant nature - so for example a FK check needs to be checked which could potentially cause an operational overhead. Unless you have benchmarked this to be the case, I would not recommend you believing this to be the case as default as per the links above, you may find out otherwise.

When we have seen conversion of table engine from MyISAM to Innodb as being most beneficial?

If you need ACID compliance and need your db to be transactional then choosing Innodb is an obvious choice and you ought to make the necessary conversion including adding any FK constraints, etc if you need them. If you are not disproportionately read-only heavy and are doing a mix of reads (not requiring full text indexing) and writes then we do recommend that you go with Innodb. Most commonly we have observed that MyISAM tables would rather be converted to Innodb when you face frequent table lock escalations for long periods of time. If a read is slow or hasn't completed and a read/write is waiting on the first read to finish then the MyISAM table referenced in the read is held in a locked state till the resultset is made available to the query. This also causes a rise in the load average on the server and slows your site down. During this time no reads or writes can complete ofcourse as MyISAM only has table-level locking. So to summarize, the queries that are victims of lock escalations under heavy but slow reads would do much better as a table converted to Innodb.

back mysql dbfile

sudo mkdir mysql_bak && sudo chown mysql:mysql mysql_bak

sudo /etc/init.d/mysqld stop
sudo cp -r mysql/ mysql_bak/

by alter

mysql -uroot -proot

-- sql_file
show databases;
use  guanxi_manager_production;
show tables;
ALTER TABLE oper_logs ENGINE = InnoDB;

mysql -uroot -proot < sql_file

by dump

use guanxi_manager_production
show create table oper_logs;

create table oper_logs like oper_logs;

ALTER TABLE oper_logs_bak ENGINE = InnoDB;
show create table oper_logs_bak;

export

mysqldump -uroot -proot --no-create-info guanxi_manager_production oper_logs > /data/mysql_bak/dump/guanxi_manager_production_oper_logs.sql &

RENAME TABLE oper_logs TO oper_logs_old;
DROP TABLE IF EXISTS oper_logs;

RENAME TABLE oper_logs_bak TO oper_logs;

TRUNCATE oper_logs;

restore

mysql -uroot -proot  guanxi_manager_production < /data/mysql_bak/dump/guanxi_manager_production_oper_logs.sql &
# or
mysql -uroot -proot < restore_sql &

-- restore_sql
use guanxi_manager_production
set names utf8;
source /data/mysql_bak/dump/guanxi_manager_production_oper_logs.sql;

$ hexedit largefile.sql.dump
tab (switch to ASCII side)
space (repeat as needed until your header is gone)
F2 (save)/Ctrl-X (save and exit)/Ctrl-C (exit without saving)

DROP TABLE IF EXISTS `oper_logs`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `oper_logs` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `action` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  `userid` int(11) DEFAULT NULL,
  `version` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `platform` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `result` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `user_index` (`userid`),
  KEY `my_index` (`action`,`userid`),
  KEY `time_index` (`created_at`)
) ENGINE=MyISAM AUTO_INCREMENT=150747096 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
/*!40101 SET character_set_client = @saved_cs_client */;

What is payload?

When data is sent over the Internet, each unit transmitted includes both header information and the actual data being sent. The header identifies the source and destination of the packet, while the actual data is referred to as the payload. In general, payload is the data that is carried on behalf of an application and the data received by the destination system.

SOAP(Simple Object Access Protocol) vs REST(Representation State Transfer) (differences)

SOAP and REST can't be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn't SOAP.
Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations. A SOAP client works like a custom desktop application, tightly coupled to the server. There's a rigid contract between client and server, and everything is expected to break if either side changes anything. You need constant updates following any change.
A REST client is more like a browser. It's a generic client that knows how to use a protocol and standardized methods, and an application has to fit inside that. You don't violate the protocol standards by creating extra methods, you leverage on the standard methods and create the actions with them on your media type. If done right, there's less coupling, and changes can be dealt with more gracefully. A client is supposed to enter a REST service with zero knowledge of the API, except for the entry point and the media type. In SOAP, the client needs previous knowledge on everything he will be using, or it won't even begin the interaction. Additionally, a REST client can be extended by code-on-demand supplied by the server itself, the classical example being javascript code used to drive the interaction with another service on the client-side.
I think these are the crucial points to understand what REST is about, and how it differs from SOAP:
- REST is protocol independent. It's not coupled to HTTP. Pretty much like you can follow an ftp link on a website, a REST application can use any protocol for which there is an standardized URI scheme.
- REST is not mapping CRUD to HTTP methods. Read this answer for a detailed explanation on that.
- REST is as standardized as the parts you're using. Security and authentication in HTTP is standardized, so that's what you use when doing REST over HTTP.
- REST is not REST without HATEOAS. This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow. Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely. They are not only documenting something that's supposed to be following the standard, but when you do that, you're coupling the client to one particular moment in the evolution of the API, and any changes on the API have to be documented and applied, or it will break.
- REST is the architectural style of the web itself. When you enter Stack Overflow, you know what a User, a Question and an Answer are, you know the media types, and the website provides you with the links to them. A REST API has to do the same. If we designed the web the way people think REST should be done, instead of having a home page with links to Questions and Answers, we'd have a static documentation explaining that in order to view a question, you have to take the URI stackoverflow.com/questions/{id}, replace id with the Question.id and paste that on your browser. That's nonsense, but that's what many people think REST is.
- This last point can't be emphasized enough. If your clients are building URIs from templates in documentation and not getting links in the resource representations, that's not REST. Roy Fielding, the author of REST, made it clear on this blog post: REST APIs must be hypertext-driven.
- With the above in mind, you'll realize that while REST might not be restricted to XML, to do it correctly with any other format you'll have to design and standardize some format for your links. Hyperlinks are standard in XML, but not in JSON. There are draft standards for JSON, like HAL.
- Finally, REST isn't for everyone, and a proof of that is how most people solve their problems very well with the HTTP APIs they call REST and never venture beyond that. REST is hard to do sometimes, especially in the beginning, but it pays over time with easier evolution on the server side, and client's resilience to changes. If you need something done quickly and easily, don't bother about getting REST right. It's probably not what you're looking for. If you need something that will have to stay online for years or even decades, then REST is for you.
Now for example I have to send a Telegram and we all know that the cost of the telegram will depend on number of words.So tell me among below mentioned these two messages, which one is cheaper to send?

 <name>Arin</name>

 "name": "Arin"

I know your answer will be second one although both representing the same message second one is cheaper in terms of cost. So I am trying to say that, sending data over the network in Json format is cheaper than sending it in Xml format in terms of payload.
- Here is the first benefit or advantages of REST over SOAP. SOAP only support XML, but REST supports different format like text, JSON, XML etc. And we already know, if we use Json then definitely we will be in better place in terms of payload. Now, SOAP supports only XML, but it also has its own advantages. Really! How?
- SOAP relies on XML in three ways Envelope – that defines what is in the message and how to process it.
- A set of encoding rules for data types, and finally the layout of the procedure calls and responses gathered.This envelope is sent via a transport (HTTP/HTTPS), and an RPC (Remote Procedure Call) is executed and the envelope is returned with information in a XML formatted document.
- Here important point is that one of the advantages of SOAP is the use of the “generic” transport but REST uses HTTP/HTTPS. SOAP can use almost any transport to send the request but REST cannot. So here we got an advantage of using SOAP.
- As I already mentioned in above paragraph “REST uses HTTP/HTTPS”, so go bit deeper on these words.
- When we are talking about REST over HTTP, all security measures applied HTTP are inherited and this is known as transport level security and it secures messages only while it is inside the wire but once you delivered it on the other side you don’t really know how many stages it will have to go through before reaching the real point where the data will be processed. And of course all those stages could use something different than HTTP.So Rest is not safer completely, right?
- But SOAP supports SSL just like REST additionally it also supports WS-Security which adds some enterprise security features. WS-Security offers protection from the creation of the message to it’s consumption. So for transport level security whatever loophole we found that can be prevented using WS-Security.
- Apart from that, as REST is limited by it's HTTP protocol so it’s transaction support is neither ACID compliant nor can provide two phase commit across distributed transnational resources. But SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.
- I am not drawing any conclusion, but I will definitely prefer SOAP based web service while security, transaction etc are the main concerns.

dhavalv/question_answers_notes.md