Pantene742

Laravel ORM поддерживает MsSQL из коробки.
Для этого достаточно прописать переменную в нужной модели

class Foo extends Model {

    protected $connection = 'sqlsrv';

Данные для доступа прописывайте в config/database.php

Нет никакой разницы.
При использовании Vagrant, Docker или просто виртуальных машин.

Есть минимальная разница при тестировании непосредственно под Линукс.

Вас кто-то обманул, говоря, что "прочие" языки заточены под Unix.

Все языки - универсальны.

А вот конкретные библиотеки или т.п. - те могут быть заточены....

Редкие пакеты Go ведут себя по иному в различных операционных системах.
Скажем, не работает syslog даже в MacOS X. Ну и в Windows не работает.
Так как это является специфической для операционной системы вещью.

Большая часть же программ на Go - является абсолютно переносимой.


Конечно, если ты заточешься на использования чисто Windows API, то программа не переедет просто так. Но ты обязательно заметишь, что ты затачивашься на Windows, так как для этого тебе понадобятся дополнительные специальные пакеты для Windows.

При этом если твоя работа ограничена сетью, файлами - то нет никакой необходимости затачиваться под Windows. Твоя программа будет идентично работать под любой платформой.

Как только ты начинаешь писать пользовательский интерфейс, то тут и возникает привязка. А как ты будешь писать пользовательский интерфейс? Если через web, то нет никакой привязки к Windows.

Если ты же ты пожелаешь использовать оконную систему Windows, то уже появляется привязка к Windows.

Есть еще т.н. кросс-системные библиотеки пользовательского интерфейса (Qt и т.п.), на них, к примеру, написан LiteIDE (это такое IDE под Go, которое написано с помощью самого Go). Посмотри его исходники.

LiteIDE - не привязан к операционной системе. Хотя и обладает вполне себе приемлимым пользовательским десктопным интерфейсом.

Насколько я знаю разработка на языках Python, Ruby, PHP под Windows имеет много нюансов. Не работают многие стандартные функции данных языков. Заточен ли Go также под Unix подобные системы так же, как, интерпритируемые языки ?. Или же на нем как на C++, можно писать под любую систему Но платформенно зависимые программы ?

Что-то вы не то знаете.
Все эти языки примерно одинаково переносимы между платформами.

Исключения лежат на поверхности:

если вы будете использовать пути файлов в стиле Windows ( C:\mycatalog\myfile ) или в стиле Unix ( /mycatalog/myfile ). Но вас никто не заставляет это делать. Так как внутри стандартных библиотек всех этих языков, как правило есть функции, которые позволяют работать с именами файлов независимо от системы.

также не получится работать с сокетами unix если вы под Windows. Если вы всегда используете TCP/IP, то нет никаких проблем с переносимостью.

Если вы про то, что программы не идеально работают на других системах, то это не проблема Windows. Вы можете написать на С++ программу на Ubuntu 14.04 LTS и она не скомпилируется на Ubuntu 16.04 LTS.

На любом языке, от Ассемблера до Хаскелля, используйте биндинги для WinAPI, и получите прибитое гвоздями к винде приложение.

На C++ вполне можно писать код, работающий на любой платформе.

Вообще, тут должно быть достаточно.
Из видеоуроков kudvenkat один из лучших.
Мне еще нравилось это, достаточно неплохо написано. Руководство по c# вообще очень похоже на Троелсена.
Вообще основной совет - пробегайтесь по основам и пишите проект, который вам интересен/полезен, так как у меня лично маловато подробностей остается после простого прочтения. В крайнем случае попробуйте начать, к примеру с этого.

Вот книги которые рекомендую прочесть.
Джеффри Рихтер - CLR via C#
Эндрю Троелсен - Язык программирования C# 5.0 и платформа .NET 4.5
GoF - Design Patterns
Роберт Мартин - Чистый код

Из необязательного
Джозеф Албахари, Бен Албахари - C# 6.0. Справочник. Полное описание языка

Нюанс №1: Чем более похожи среда разработки и среда продакшена, тем меньше сюрпризов тебя ожидает.
Нюанс №2: Некоторые библиотеки на винду ставятся только под горловое пение шамана с бубном и только при определённой фазе луны.
Нюанс №3: Python 2.7 скоро уйдёт в легаси, учиться ему в 2016 году, как минимум, странно (хотя, не так уж и странно, если вспомнить, чего хочет автор вопроса).
Нюанс №4: Если тебе лень поставить линуху на ПК (а фразу "Переходить на Linuх также не хочу" в данном контексте иначе никак не интерпретируешь) - что будет, когда ты возьмёшь первый проект? Скажешь: "Чёт мне лень, пойду каточку в дотан сыграю"?

Собственно эта вот строка:
if (!($this->stream = fopen($this->path, 'rb'))) {
намекает на то, что скрипт открывает файл только на чтение, так что проблем у параллельных процессов с доступом к этому файлу как-бы совсем нет.

Проблема может быть в количестве одновременно запущенных процессов php. 1000 коннектов = 1000 запущенных процессов, каждый процесс кушает запросто мегабайт 50. Оперативной памяти серверу хватит? :)

Все вопросы авторизации лучше доверить профессионалам:
erlyvideo.ru/doc/auth

Вы дампите $row, а результат сохраняете в $rows

А что nodejs-то делать будет? Все обойти можно, хоть nodejs, хоть что.

Достаточно php и nginx с защитой от хотлинкинга.

blog.poiuty.com/delaem-video-portal.html

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

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

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

Docker - это одна программа внутри индивидуального окружения с индивидуальной версией операционной системы. За счет слоеных контейнеров, если вы используете один корень для всех образом, то размер Docker контейнера всего-то на несколько килобайтов больше размера бинарного файла, запускаемого под Docker.

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

Контейнеры существовали и до Docker. Докер, строго говоря, это всего лишь очень удобный набор инструментов, собранных воедино, для управления контейнерной виртуализацией. Но очень удобный.

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

Вплоть до того, что идеально написанная и оттестированная программа на реальном сервере начинает себя вести непредсказуемо.

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

Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

Может сложиться ложное впечатление, что разработчик готовит контейнеры в Докер, а потом передает их админу.
Правильная методология все же другая:

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).

Разобрался.

socket = io.connect('http://url.ru:8080', {transports: ['websocket', 'flashsocket', 'xhr-polling']});

Нет, не умрет. pcntl_fork() делает копию родительского процесса который работает самостоятельно.

$pid = pcntl_fork();
if ($pid == -1) {
    echo "fork error\n";
    exit;
} elseif ($pid > 0) {
    // завершаем работу родительского процесса
    exit;
}

В результате работы такого кода например, основной процесс будет убит сразу после запуска дочернего процесса. Собственно так реализуется отвязка от терминала.