YaroslavZinchenko

С точки зрения архитектуры:

Интерфейс описывает свойства. Обратите внимание на классические названия интерфейсов: Throwable, Countable, Comparable, Iterable и т.д. Возьмем, к примеру, интерфейс Rollable (катящийся), и Foldable (складывающийся).

Абстрактный класс же описывает сущность. Например, стол: Table_Abstract. Стол может быть деревянным, тогда будет Table_Wood extends Table_Abstract. Также стол может быть хирургическим: Table_Surgical extends Table_Abstract. В таком случае Table_Abstract объединяет общий свойства всех столов (скажем, площадь поверхности, наличие ножек и т.п.). А конкретный класс описывает сущность определенного типа столов.

Связью же интерфейсов и классов Вы описываете свойства. Например, стол можно катить: Table_Abstract implements Rollable. Деревянный стол, например, можно сложить: Table_Wood implements Foldable.

Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
> Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 3-4 метода, и все они связаны простой идеей, то и выделять ничего не надо. Когда у класса уже 10 методов, и среди них есть небольшие смысловые группы, то уже имеет смысл эти группы подчеркнуть. И, в конце концов, вместо каши из 10 методов, вы читаете следующее: class Graph : IEnumerable, IIndexable, IDrawable - и вы знаете, что ваш граф перечисляется, индексируется и рисуется. Это уже очень много информации, вы уже понимаете, как взаимодействуют части вашей системы.

> Может создано это для работы в больших коллективах? Но ведь тогда любой участник сможет поправить и интерфейс.
Да, совершенно верно, для больших коллективов. Нет, участник просто так не сможет поправить интерфейс, не побеседовав с остальными. В лучшем случае участнику придется поправить весь код, который "висит" на этом интерфейсе, в худшем - он в принципе ничего не сможет поменять, если интерфейс "публичный" и используется несколькими командами разработчиков. Классический пример - системы плагинов. Если к MS Word-у уже написано куча плагинов, то MS не может взять и просто так поменять ифейсы, не поломав совместимость. Хотя некоторые аспекты реализации - может. Потому что, как уже сказали выше, интерфейс - это ДОГОВОР. Чем БОЛЕЕ он стабилен, тем ЛУЧШЕ. Команды договариваются (!), создавая интерфейсы, чтобы потом было как можно МЕНЬШЕ конфликтов и разногласий, т.к. проблемы с интерфейсом затрагивают всех. Найдите любую команду от 30 человек, и вы увидите, насколько это все важно.

Еще две вещи напоследок:
1) интерфейсы из ОО языков лишь частный пример понятие интерфейса в жизни вообще. Вы же, когда покупаете SATA-диск, наверное рассчитываете, что сможете его подключить к своему компу? А с чего вы взяли? А, ну конечно, ведь на упаковке написано SATA - значит производитель соблюдает ДОГОВОР - интерфейс передачи данных;
2) необходимость в некоторых фичах языков сложно осознать в личных проектах и даже в маленьких командах. Это тоже как в жизни: свой дом, как говорится, должен построить каждый мужик, а чтобы построить бизнес-центр или высотку, нужны определенные знания, т.к. другие масштабы. Это нормально. Тем не менее, нужно читать и искать примеры. Хотя современные ОО-языки и сами дают много примеров. Раз у вас PHP, почитайте про Iterator например.

Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

interface FileSystemInterface {
  public function write($file, $data);
  public function read($file);
}

Затем, хочу реализацию интерфейса ФС для работы с файликами:

class OSFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем файлик, пишем данные
  }

  public function read($file) {
    // открываем файлик, возвращаем данные
  }
}

Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:

class CloudFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем соединение с облаком, пишем данные
  }

  public function read($file) {
    // открываем соединение с облаком, возвращаем данные
  }
}

Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

class FileStorage {
  protected $Fs;
  
  public function __construct(FileSystemInterface $Fs) {
    $this->Fs = $Fs;
  }  

  public function saveFile() {
    $this->Fs->write('file.txt', 'file data');
  }

  public function getFile() {
    return $this->Fs->read('file.txt', 'file data');
  }
}

Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

// Хранилище файлов работает с файловой системой ОС:
$FS = new OSFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

// Хранилище файлов работает с файловой системой в облаке:
$FS = new CloudFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

Использование интерфейса, в данном случае. позволяет нам писать только реализацию работы файловой системы, а бизнес-логика, работающая с файловой системой никак не меняется, она знает, что в любом случае файловая система реализует интерфейс FileSystemInterface и может без опаски использовать методы этого интерфейса.

В ошибке написано что ты делаешь не так - используешь метод, недоступный с сервисным ключом, используя при этом сервисный ключ.
"Этот метод можно вызвать с ключом доступа пользователя."

Загружать видео можно только в том случае, если все запросы к VK API осуществляются с сервера. В документации написано, как загружать видео, но я расскажу поподробнее. Ход действий примерно такой:

1. Загрузите видео на свой сервер.
   
2. Вызовите метод video.save. Указывать какие-либо параметры не обязательно, но можете указать, например, ID группы, в которую будет добавлено видео, в параметре group_id и имя видеозаписи в параметре name.
   
3. После того, как вы вызовете метод video.save, вы получите ссылку, куда надо будет загрузить вашу видеозапись. Выглядеть ответ от ВК будет примерно так:
   
   

   response: {
     upload_url: 'http://cs12129.vkontakte.ru/upload_video.php?act=add_video&mid=15748&oid=66748&vid=164322743&fid=0&tag=122517f2&hash=8bf2ea4bb66ca67d28fb&swfupload=1',
     vid: 164322743,
     owner_id: 66321,
     name: 'No name',
     description: '',
     access_key: 'e6822bfb86f90a149c'
   }

   
   По этому адресу методом POST отправьте видеозапись в поле video_file.
   
   
4. В ответ на загрузку видеозаписи ВК вернёт вам ID видеозаписи:
   
   

   {
     "size":1234,
     "video_id":1234567
   }

   
   

Это всё. Видеозапись должна будет появиться в указанном вами сообществе.

Небольшой пример на PHP:

<?php

define('VK_ACCESS_TOKEN', '533bacf01e11f55b536a565b57531ac114461ae8736d6506a3');
define('VK_API_VERSION', 5.53);

// // //
// Скачиваем видео с внешнего сервера на свой сервер
// // //

$ch = curl_init();
				
curl_setopt($ch, CURLOPT_URL, 'http://cache-spb07.cdn.yandex.net/kp.cdn.yandex.net/558075/kinopoisk.ru-L_odyss__233_e-311292.mp4');
curl_setopt($ch, CURLOPT_HTTPGET, TRUE);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_BINARYTRANSFER, TRUE);

$curl_result = curl_exec($ch);

curl_close($ch);

// Кладем видео в папку со скриптом
$fp = fopen('kinopoisk.ru-L_odyss__233_e-311292.mp4', 'x');
fwrite($fp, $curl_result);
fclose($fp);

// // //
// Получаем адрес ссылки, куда загружать видео
// // //

$ch = curl_init();
$parameters = http_build_query([
    'access_token' => VK_ACCESS_TOKEN, // access_token / ключ доступа
    'v'            => VK_API_VERSION, // версия API
    'name'         => 'Имя видеозаписи',
    'description'  => 'Исчерпывающее описание нашей первой видеозаписи.',
    'group_id'     => 125004421, // ID группы
    'no_comments'  => 0 // разрешаем комментирование
]);

curl_setopt($ch, CURLOPT_URL, 'https://api.vk.com/method/video.save?' . $parameters);
curl_setopt($ch, CURLOPT_HTTPGET, TRUE);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);

$curl_result = json_decode(curl_exec($ch), TRUE); // превращаем JSON-массив, который нам вернул VK, в обычный PHP-массив

curl_close($ch);

// // //
// Загружаем видео на серверы ВК
// // //

$ch = curl_init();
$parameters = [
    'video_file' => new CURLFile('kinopoisk.ru-L_odyss__233_e-311292.mp4')  // PHP >= 5.5.0
    // 'video_file' => '@kinopoisk.ru-L_odyss__233_e-311292.mp4' // PHP < 5.5.0
];

curl_setopt($ch, CURLOPT_URL, $curl_result['response']['upload_url']);
curl_setopt($ch, CURLOPT_POST, TRUE);
curl_setopt($ch, CURLOPT_POSTFIELDS, $parameters);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_SAFE_UPLOAD, TRUE); // если PHP < 5.5.0, то эту строку надо закомментировать

$curl_result = json_decode(curl_exec($ch), TRUE);

curl_close($ch);

if (isset($curl_result['error'])) {
    exit('Строка ' . __LINE__ . ': Ошибка при загрузке видео на серверы ВК: ' . $curl_result['error'] . '.');
}

echo 'Видеозапись успешно загружена.';

Кстати, параметр link метода video.save принимает только ссылки на популярные видеохостинги, вроде YouTube. О работе через этот параметр я писал в этом вопросе.

Мое ИМХО - хороший маркетинг и надежная работа под высокой нагрузкой.

Gitlab появился сравнительно недавно.
Его ценность не в его web сервисе а в том что можно быстро и безболезненно поднять это всё дело локально на своих серверах.

Конечно они пытаются откусить кусок у битбакета и гитхаба но пока это не особо получается, хотя может у них и есть некий интерпрайз в пользователях но статистики не видел.

Ведь есть gitlab?

gitlab в основном используется для реализации своих приватных репозиториев и только. Для всего остального есть github.

Во-первых, большинство сторонних сервисов, полезных при разработке (ci серверы, анализаторы кода, багтрекеры, agile доски), работают только с гитхабом. Одно это уже является критическим доводом использования гитхаба.

Во-вторых, всё современное девелоперское комьюнити сидит на гитхабе. На гитхабе все были, им все пользуются, он всем привычен. Поэтому вполне естественно именно его выбирать как хостинг для своего кода.

В-третьих, активность на гитхабе может выступать в роли вашего резюме. Если вы активный контрибьютор опенсорс проектов, это может очень сильно помочь при смене места работы.

В четвёртых, на гитхабе есть целая куча разных мелких удобных вещей, которых нет на его аналогах. В него вкладывают много денег, его активно развивают, поэтому в нём больше всяких "фич".