Код нужно писать не как попало, а аккуратно и по правилам. Почему? Потому, что на неакуратно написанный код не хочется даже смотреть.

Если тебе лень выравнивать код руками, закачай его на http://beta.phpformatter.com/ и нажми «format». Робот исправит выравнивание и отступы в мгновение ока (да, прогресс не стоит на месте). Если ты используешь мощную IDE вроде PhpStorm, там тоже есть функция форматирования кода.

Горячие клавиши для форматирования кода в разных IDE: https://gist.github.com/codedokode/8759492

Вообще, в PHP долгое время не было единого стандарта оформления кода, все писали как попало и было много бардака, но сейчас дело лучше — есть стандарты PSR-1 и 2. Вот как надо оформлять код:

- переменные и функции пишутся с маленькой буквы, подчеркивание не используется, используется camelCase, пример: $x, $numberOfPeople, printResults()
- Название функции начинается с глагола, в стиле «сделайЧтоТо»
- не знаешь английский? Не беда, в 21 веке есть решение этой проблемы. Не пиши транслитом, открой лучше Гугл Транслейт или slovari.yandex.ru и найди название для переменной там
- в именах классов используется CamelCase, первая буква большая, «_» может использоваться
- мы предпочитаем подстановку переменных вместо конкатенации строк: "I am $age years old" — хорошо, 'I am ' . $age . ' years old' — плохо из-за обилия точек и кавычек
- мы используем для отступов 4 пробела (можно настроить редактор, чтобы при нажатии Tab он вставлял 4 пробела)

Вот ссылка на стандарты, где все это описано подробнее и даны примеры оформления:

PSR-1: https://github.com/samdark/fig-standards-ru/blob/master/accepted/ru/PSR-1-basic-coding-standard.md
PSR-2: https://github.com/samdark/fig-standards-ru/blob/master/accepted/ru/PSR-2-coding-style-guide.md

------------------

Итак, ты зашел в тред и решил помочь какому-то анону, дав ему совет или подсказку. Спасибо! Но прочти сначала эти напоминания, чтобы твоя помощь действительно была полезной.

Давай удочку, а не рыбу

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

Будь доброжелателен

Не годится: «Ты мануал хоть раз в жизни открывал, обезьяна?»
Не годится: «В гугле забанили?»
Не годится: «Твой код плохой»
Хорошо: «Вот, как можно улучшить этот код: ...»
Хорошо: «Ты неправильно используешь функцию abc(). Вот ее описание: ссылка, и как видишь ей надо передать строку, а не массив»

Не придирайся к знанию английского или русского языка.

Объясняй

Не очень хорошо: «сделай как в этом коде»
Хорошо: «если ты вставляешь текст от пользователя в SQL запрос, то получается SQl-инъекция, которая позволяет взломать твой сервер (ссылки). Чтобы этого избежать, надо вставлять данные с помощью плейсхолдеров (ссылки)»
Хорошо: «Помни, что код пишется для людей. Если писать такие большие функции, то в них становится трудно разобраться...»

Не проповедуй

Мы учим использованию самых распространненных подходов, стандартов, библиотеки фреймворков. Если ты не любишь ООП, пробелы в коде, jQuery, сам PHP, то рассказать об этом стоит в каком-нибудь другом треде.

Не придирайся к знанию английского языка, анон пишет как умеет.

Ах да. Если тебе кажется, что что-то в учебнике или задачах можно сделать лучше — пиши, обратная связь всегда очень полезна.

>>897549
Кажется я начинаю всё понимать

>Изучив теорию, советую ответить на вопрос: чему будет равен (или на какой объект будет указывать) this внутри функции в следующих случаях:

>1)

>function x() { }; x();

this будет в контексте объекта-функции x()

>2)

>var z = {};

>z.test = function () {};

>z.test();

this будет в контексте объекта z

>3)

>var z = {};

>z.test = function() {};

>var fn = z.test;

>fn();

this будет в контексте объекта fn, т.е. функции-объекта z.test

Ещё можно добавить четвертый пример:
4)
var z = {};
z.test = function() {};
var fn = z.test.call(z);
fn();
В котором this будет в контексте объекта z

>Лучше не ужасаться, а написать, что именно непонятно, и попросить совет. В нашем треде обычно всегда что-нибудь посоветуют.

Нужно стараться решать самому

>>897643

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

>Если тебе не очень нравятся абстрактные задачи, ты ведь знаешь HTML, ты можешь попробовать начинать параллельно делать что-нибудь посложнее, можно игру в сапера, можно игру "арканоид" ( https://gist.github.com/codedokode/9933897 ) или, например, какое-нибудь простое приложение, если тебе не нравятся игры (например, написать простую электронную таблицу вроде экселя). Главное, чтобы это было на какую-то интересную тебе тему.

Мне интересно как делается динамическая подгрузка контента. Думаю, я мог бы сделать страницу с простым чатиком в задаче с Студентами, но я не знаю с чего начать. Это же ajax или уже есть что-то получше?

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

>>898604

Увы, пока неправильно. Вот разберем например это:

>>function x() { }; x();

> this будет в контексте объекта-функции x()

Что значит "будет в контексте"? Не очень понятная фраза. Давай попробуем проверить экспериментально. Открой отладчик браузера и введи туда

function x() { console.log(this); }
x();

И посмотри, что выведется в консоль.

Аналогично и с другими примерами.

Это все-таки основы языка, без них трудно будет что-то писать.

> Нужно стараться решать самому

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

> Мне интересно как делается динамическая подгрузка контента.

Да, это надо изучать аякс и XMLHttpRequest ( https://developer.mozilla.org/ru/docs/Web/API/XMLHttpRequest - тут правда не очень подробно описано, так что придется еще погуглить). И разумеется, надо знать основы протокола HTTP, что такое методы, заголовки, Content-Type и тд. У меня есть недописанный урок: https://github.com/codedokode/pasta/blob/master/network/http.md

И разумеется, надо изучить DOM, чтобы знать, как например вставить на страницу новое сообщение.

Чат - хорошая идея, можешь попробовать сделать.

>>899573

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

У иммутабельных объектов есть преимущества и недостатки:

- иммутабельные объекты создаются при любом изменении, больше расход ресурсов. Особенно неэффективно, например, циклом менять строку по 1 символу - каждый раз создается новый объект
- с другой стороны, иммутабельность позволяет для 2 одинаковых строк не создавать 2 объекта, а использовать один и тот же: $a = $b = new String(..). В случае с мутабельными объектами так делать нельзя, так как при изменении строки в одной переиенной она поменяется и в другой.
- с другой стороны, ты знаешь, что если ты передал куда-то такой объект, никто его не поменяет. Это позволяет так же иногда делать какие-то оптимизации. Ну например если ты взял из объекта длину строки, ты можешь сохранить ее и не бояться что длина поменяется.
- в многопоточных программах параллельный доступ из нескольких потоков к таким объектам не требует блокировки (в случае мутабельных объектов в один момент времени с ним должен работать только один поток и нужна блокировка)
- очень легко проверить, что строка изменилась с помощью $s1 !== $s2: если строка изменилась, то там будет другой экземпляр объекта. В случае мутабельных объектов, нам надо сохранять копию объекта и позже сравнивать каждое свойство. Вот пример кода:

$s1 = new String(...);
$s2 = someFunction($s1);
if ($s2=== $s1) { echo "Строка не изменилась"; } else { echo "Возможно, это другая строка"; }

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

https://habrahabr.ru/company/mailru/blog/301004/

https://ru.wikipedia.org/wiki/Неизменяемый_объект

https://ru.wikipedia.org/wiki/Неизменяемый_интерфейс

В PHP есть неизменяемые объекты даты/времен: http://php.net/manual/en/class.datetimeimmutable.php

Есть предложение добавить синтаксис для таких классов: https://wiki.php.net/rfc/immutability

Иммутабельность в яваскрипте: https://habrahabr.ru/company/devexpress/blog/302118/

Прочитай внимательно, сравни преимущества и недостатки. А ты думал, ты строку за 5 минут спроектируешь?

>>888015
>>899152

База данных

> https://github.com/fidnex/filehost/blob/master/dump.sql

Тут надо проставить внешние ключи (ADD CONSTRAINT FOREIGN KEY), для колонок вроде parent_id, file_id, ссылающихся на другие поля таблиц.

> `author` varchar(255) NOT NULL DEFAULT 'anonymous'

Лучше по умолчанию записывать null, а при выводе заменять. А то не отличить тех, кто не ввел имя, от тех, кто ввел anonymous.

Файлы настроек

У структуры кода, которая используется (с вынесенем файлов settings.php, dependencies.php), я вижу такой недостаток:

- нет bootstrap-файла. Если ты например захочешь добавить скрипт командной строки, и в нем исплоьзовать контейнер и настройки, то придется копипастить код создания $app из index.php.

Мне бы больше понравилась такая структура: файл bootstrap.php, который инициализирует приложение, задавая настройки и сервисы в контейнере. А роуты можно прописать либо в отдельном файле либо в самом index.php.

Как я понимаю, эту схемы ты не сам придумал, а взял из шаблона приложения на Slim (Slim-Skeleton). Я даже писал авторам этого шаблона, высказав те же мысли, но они написали, что их такая схема устраивает.

Также, в settings.php очень много настроек. Возможно (пользователям) было бы удобнее, если бы настройки, которые пользователь может менять, были бы вынесены в один конфиг, а которые не может - в другой. В более сложном приложении получится очень большой конфиг, в котором будет трудно разобраться. В Симфони например эта проблема решается тем, что есть файл конфига config.yml, и есть файл с изменяемыми параметрами parameters.yml.

В твоем случае изменяемые настройки - это например имя базы данных. А неизменяемые - это например драйвер базы данных или template_path.

Соответственно, неизменяемые параметры конфига вроде settings.resize, или templates_path, если они используются только 1 раз, можно даже прописать прямо в контейнере. А можно конечно и в конфиге.

DI контейнер

Еще мне не очень нравится такая штука:

> $view->addExtension(new \Slim\Views\TwigExtension(

> $c['router'],

> $c['request']->getUri()

> ));

Не очень хорошо, что экземпляр request используется в контейнере.

Сервисы - это классы, которые обычно существуют в одном экземпляре, и не представляют какую-то сущность, а содержат полезные методы. И обычно сервисы не должны иметь в зависимостях HTTP запрос, так как в теории они могут служить для обработки нескольких запросов. Или их можно вызывать из скриптов командной строки, где никакого запроса нет. У тебя twig нельзя использовать в скрипте для командной строки, так как там нет объекта request. А необходимость может быть, например, чтобы сгенерировать письмо по twig-шаблону.

Кстати, такие проблемы много где есть. В Симфони роутер (и генератор URL) в качестве зависимости получает HTTP-запрос. Если его вызвать из скрипта командной строки, он может генерировать URL вида http://localhost/... (так как он привык брать имя домена из заголовка запроса HTTP_HOST, а тут его нету). Это указывает на ошибку в проектировании (или в настройке) генератора URL в данном случае.

Более того, в гитхабе библиотеки Slim-Views в конструктор ничего не передается: https://github.com/slimphp/Slim-Views#twig-1

Это не ошибка? Или у тебя более старая версия?

> $capsule->setAsGlobal();

Вот тут ты делаешь экземпляр объекта доступным через статические методы (Capsule::table(..)). Но тут есть проблема, что мы не знаем точный момент, когда будет выполнена эта строчка (setAsGlobal), и, соответственно, не можем сказать, с какого момента можно использовать статические методы. Она ведь не сработает, пока кто-то не запросит экземпляр $container->db. Эту строку надо было помещать не в контейнер, а после него, чтобы объект был гарантированно создан в начале программы:

$container->db->setAsGlobal();

Либо же мы бы могли сделать функцию $container->initDatabase() и вызывать ее перед созданием сервисов, которым нужна база данных.

А сейчас у тебя все работает с расчетом на то, что кто-то создаст сервис db до того, как попытается воспользоваться какими-то методами Eloquent. Это ненадежно, надо явно создать нужный объект.

Вот этот код очень нелогичный:

> $container['filesModel'] = $container->factory(function ($c) {

> $c->db;

> return new App\Models\Files;

> });

Какой смысл в строчке $c->db? Никакого. Ты видимо полагаешься на побочные эффекты (вызов setAsGlobal) от создания сервиса db. Побочные эффекты это плохо, и они неочевидны при чтении кода. Не надо так, это как раз то, с чем борется dependency injection. Если бы сервис принрмал $db как аргумент, было бы так:

return new App\Model\FilesTable($c->db);

Но Eloquent вроде не позволяет передать объект БД в модели. Их схема с статическими методами не очень хорошо сочетается с DI контейнером. Это в общем-то проблема паттерна Active Record, потому что там возможен такой код:

$user = new User;
$user->save();

Или такой: $users = User::all();

И тут непонятно, где User берет соединение с БД. Эту проблему теоретически можно решить, если явно передавать объект БД в конструктор (new User($db)) или если создавать объекты не самому ($user = $db->createUser()), но обычно Active Record получает объект БД через статические методы со всеми вытекающими последствиями. Как я понимаю, причина в том, что laravel скопирован с ruby on rails, а там хотят минимум настроек и конфигурации и потому они хотят использовать статические методы вместо DI.

И еще, как я понимаю, в Eloquent объект App\Model\Files одновременно представляет и одну запись из базы, и объект, позволяющий делать операции над таблицей. И вдобавок еще можно использовать статические методы вроде Files::take(10). Потому код выглядит не очень логично: где-то ты получаешь Files из контейнера, а где-то создаешь через new.

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

>>888015
>>899152

MainController

Еще мне не нравятся такие вещи:

> foreach ($files as &$file) {

> $file->downloadUrl = $this->router->pathFor('downloadFile', array(

Это в общем плохая идея, добавлять свойства в объекты. Объекты тем и хороши, что они относятся к какому-то классу, и можно посмотреть, какие у них есть свойства. И ты знаешь, что если у тебя объект класа X, то у него есть свойства a, b, с. А если добавлять свойства динамически, то появляется путаница, где-то эти свойства доступны, где-то нет.

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

Получать viewUrl/downloadUrl удобнее наверно в самом шаблоне.

Я бы тебе советовал для начала все же учиться писать обычный ООП код с минимумом магии и побочных эффектов, а когда освоишь, можешь пробовать другие подходы. Eloquent, раз ты уж его взял, пусть остается, но постарайся его интегрировать с минимумом побочных эффектов и без странных вызовов вроде $c->db;

> $files = $this->filesModel->take($this->appSettings['listFilesCount'])->orderBy('id', 'desc')->get();

Вот тут я вижу, что ты плохо понимаешь MVC. Ты пишешь много кода в контроллере, вместо того, чтобы разбивать код на контроллер (который разбирает HTTP-запрос) и модель (которая отвечает за логику обработки данных). В данном случае должно быть примерно так:

$files = $this->filesModel->getLatestFiles($count);

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

Контроллер обычно только управляет процессом обработки запроса. Ему не надо знать как сортируются записи в базе и по каким условиям их надо выбирать.

То же самое касается обработчика запроса на загрузку файла. У тебя сейчас все в контроллере. А ведь сохранение нового файла - это часть модели. Чтобы ты лучше понял, как сделать код повторно используемым, сделай такую вещь:

Напиши скрипт командной строки, который принимает на вход имя 1 или более файлов, загружает их и выводит ссылки. Используется примерно так:

php upload.php file1.txt file2.jpg
php upload.php ＊.jpg

И на выходе получается что-то такое:

http://fileservice/id1 # file1.txt
http://fileservice/id2 # file2.jpg

Соответственно, тебе надо сделать методы загрузки (и может быть валидации) в модели. И придумать, как сделать код загрузки, не завязанный на массив $_FILES, которого не будет в консольном скрипте. Идея MVC как раз в том, что методы модели могут использоваться несколькими контроллерами и данные из нее выводиться несколькими представлениями.

Также, вот этот код непраильный:

> $newFile = $this->filesModel;

Это ведь не создает новый объект, а берет существующий из контейнера. Если второй раз выполнить эту строчку, то вернется тот же самый объект. Тут очевидно должно быть написано $x = new Files.

> $newFile->save();

> if($newFile->id) {

Вот это непонятно, а как тут может не быть id? В каком случае?

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

> return $response->withJson([

> 'text' => $file->getError(),

> 'status' => 'ERROR'

> ], 400);

Я не уверен что стоит использовать тут HTTP код 400, так как клиентские библиотеки вроде jquery с методом $.ajax не дадут тебе JSON-объект, если код ответа не равен 200. Хотя я видел случаи, когда HTTP-коды ошибок используются для сигнализирования об ошибках валидации, но это не всегда удобно.

Также, я дополнил комментарии к задаче: https://gist.github.com/codedokode/9424217 - внимательно перечитай их, ибо у тебя часть ошибок там уже описана.

В этом контроллере много кода, и он немного запутанный, надо его рефакторить: https://github.com/fidnex/filehost/blob/master/src/App/Controllers/ViewFileController.php

https://github.com/fidnex/filehost/blob/master/src/App/Views/home.twig#L14
тут SVG файл лучше вынести в отдельный файл и как-то инклудить, чтобы его можно было бы редактировать.

JS код

https://github.com/fidnex/filehost/blob/master/public/assets/file-view.js
Вот тут я вижу паттерны, которые мне не очень нравятся, а именно:

> (function(commentContainer, commentFormContainer) {

> ....

> })(document.querySelector('.addition-area'), document.getElementById('comment-form'))

Можешь объяснить, чем это лучше чем просто

var commentContainer = document.querySelector('.addition-area')

На мой взгляд, так будет проще и понятнее.

Также, мне не нравится паттерн, когда JS-файл содержит код вне функций, выполняющийся при подключении файла. Мне больше нравится идея, когда файл содержит только функции (или объекты), но ничего не делает сам при подключении. Так получается нагляднее,когда какая-то функция вызвыается явно. Хотя на практике часто пишут в внешнем файле $.ready(function () { .. }), мне это не нравится.

Если ты подключаешь JS файл в конце HTML-файла, то есть недостаток, что до момента загрузки этого файла кнопки и интерактивные элементы не работают. А вот если подключить файл в начале и использовать onclick="doSomething()" то такой проблемы нет. Хотя часто делают так, как ты сделал, но мне это не нравится.

Ты исплоьзуешь Element.closest(), но судя по https://developer.mozilla.org/ru/docs/Web/API/Element/closest это совсем новая технология и в не самых новых браузерах твой код просто не заработает.

> (function(f, w) {

По моему не очень удачные названия переменных.

Насчет перетаскивания и вставки файлов через Ctrl + V - а ты тестировал перетаскивание и копирование из разных источников? (папка, браузеры, офисные программы)? Если нет, советую протестировать, так как они часто передают информацю о файле в разных форматах.

> xhr.onreadystatechange = function() {

> if (xhr.readyState == 4) {

> if(xhr.status == 200) {

> var data = JSON.parse(xhr.responseText)

Вот тут тоже у тебя стена кода без разбиения на функции. Не надо напрямую использовать XMLHttpRequest, он неуклюжий, лучше написать отдельную функцию отправки запроса.

Аноны, старый тред утонул, но он есть в архиваче: http://arhivach.org/thread/216627/

Если вас пропустили - напомните о себе.

>>901544

Могу кое-что добавить в дополнение к написанному аноном выше. Прочитай примеры использования mysqli в мануале и обрати внимание на то, что после почти каждого вызова mysqli-функции стоит if с проверкой на ошибку. Дело в том, что mysqli сама не пишет причины ошибок, и надо ставить дополнительные if (или использовать PDO, который умеет выбрасывать исключения).

Вообще, эта проблема (скрытие информации об ошибках) есть не только в PHP. В C#, если я не путаю, если создать новый тред и в нем выбросить непойманное исключение, то тред молча завершается, а исключение теряется, если специально не проверять его наличие. Это конечно неправильно, всегда должно быть так что по умолчанию ошибка фиксруется в логи и завершает программу, а далее уже разработчик при желании может ее перехватывать.

>>901318

Можно, но с use наверно код будет красивее. А в чем проблема? Ты руками что ли use пишешь? В моем Sublime например есть плагин PHP Companion, который вставляет use при нажатии F5 на имени класса. И в любой нормальной IDE есть такая функция.

Также, неймспейсы по PSR-4 должны начинаться с большой буквы.

>>901073

Если ты пишешь что "нахватался по верхам", то это плохо. Ведь надо уверенно знать основы, чтобы изучать какие-то более сложные, высокоуровневые вещи. Прежде чем изучать фреймворк, надо знать ООП и MVC.

И соответственно, если ты захочешь сделать какой-то свой проект, ну например, чат какой-нибудь, то без базовых знаний будешь делать там элементарные ошибки.

По HTML/CSS я бы предложил решить наши задачи из ОП поста. Если ты хорошо знаешь HTML, ты их решишь за 1-2 дня все. По PHP - решить задачи на ООП (Вектор и кошки-мышки) из учебника из ОП поста, а затем например задачу про список студентов. Я вот не знаю, какой уровень в курсах, которые ты смотрел, и насколько ты их усвоил, а вот в своих задачах я уверен.

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

Насчет "сайта на CMS", CMS обычно проектируются так, чтобы делать на них сайты без программирования, за счет настройки конфигурации в админке, в лучшем случае с правкой HTML шаблонов. Это очень низкий уровень и я не советую как-то на него ориентироваться. Если ты наши более сложные задачи пройдешь, в любой CMS ты разберешься без проблем.

>>901022

Главный контроллер называется Front Controller: http://design-pattern.ru/patterns/front-controller.html

> - После вызова текущего контролера и его метода, вызывает специальный метод главного контроллера getView, в котором создаётся объект класса главного View и уже в нём вызывает функция render с передаваемыми параметрами.

А ты можешь сформулровать, что должны делать контроллеры? Что они получают на вход, что выдают на выходе? В ООП ты должен для каждого класса знать, какая у него задача, что он получает и что может вернуть.

Как я понимаю из твоего описания, у тебя контроллер должен вернуть массив данных для шаблонизатора. Но это выглядит как ограничение. А что, если ты хочешь вернуть страницу с HTTP кодом 404 или 403? Что если ты хочешь вернуть не-HTML ответ (plain text или картинку или JSON)? Удобно ли это сделать в твоей архитектуре?

Сейчас я все чаще вижу такую реализацию контроллера: контроллер получает на вход объект HTTP запроса и отдает на выходе объект HTTP-ответа. Выглядит это так:

$response = $controller->indexAction($request);
или $controller->indexAction($request, $response);

В микрофреймворках контроллер может быть функцией: function (Request $req, Resonse $res).

Иногда Front Controller анализирует названия переменных в аргументах метода. Если есть роут /news/{date} и у метода контроллера есть аргумент с именем $date (newsAction($request, $date)) то в него передается значение date из URL. Для определения имени переменной используется Reflection.

Где взять объекты Request/Response? Раньше в каждом фреймворке были свои объекты, но сейчас группа PSR смогла выработать рекомендацию, и описать интерфейсы для таких классов в PSR-7: https://www.google.ru/search?q=psr-7&newwindow=1&gbv=1&sei=s3dhWKnlJMGqswHRoaKICw

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

Также, есть популярная библиотека Symfony Http Foundation с такими объектами: http://symfony.com/doc/current/components/http_foundation.html (англ) - но она не совместима с PSR-7, потому, я думаю, лучше использовать что-нибудь совеместимое.

Я советую, если ты решишь делать эти объекты, использовать именно интерфейс PSR-7 и не изобретать очередной велосипед. Есть готовые реализации: https://packagist.org/providers/psr/http-message-implementation . Если решишь не делать эти объекты, то тогда можно брать данные напрямую из GET/POST/SERVER и самостоятельно выводить ответ.

Я бы тебе советовал посмотреть микрофреймворки вроде Slim, Silex, может что-то подчерпнешь.

> Думал создать класс Router и переложить в него часть функций

Задача роутера только проанализировать URL и выбрать контролер и метод.

>>900985

Можно запостить код, написать что именно непонятно и попросить подсказку.

>>900926

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

>>900779

Читать надо было это: http://php.net/manual/ru/install.pecl.php - там установка делается по-разному в разных случаях.

Дело в том, что PHP, как и многие открытые проекты, распространяется в виде архива кода на Си. Процессор, разумеется, выполнять исходный код не способен, потому ты должен "скомпилировать" из исходного кода исполняемый файл (в случае Windows - php.exe), который можно будет запустить. Также, PHP использует сторонние библиотеки и имеет много настроек компиляции (какие возможности включать, какой каталог использовать для определенных целей итд), потому в общем процесс сборки выглядит так:

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

То есть задача проекта PHP - дать исходный код, а его сборка - задача пользователя. Этот подход имеет то преимущество, что пользователь может максимально гибко настраивать параметры сборки под свои нужды (например не включать ненужные ему модули) и даже при желании внести какие-то правки в код.

Это довольно долго и неудобно, потому под популярные ОС добрые люди собирают PHP и позволяют скачать уже скомпилированную версию. Под Windows можно скачать PHP с сайта, под Дебианом - установить через apt-get. Под маком есть программа homebrew, которая сильно упрощает процесс сборки и сама скачивает нужные библиотеки и настраивает конфигураци. А сборку вручную делают те, кто хочет каких-то нестандартных настроек.

Обрати внимание, что бинарные файлы привязаны к конкретной ОС и архитектуре процессора (32 или 64 бита). Нельзя взять бинарник от линукса и запустить на Windows.

Расширения распространяются аналогично - в виде исходных кодов, причем для их сборки нужны еще и часть исходников самого PHP нужной версии. И популярные расширения тоже можно скачать уже скопилированные (для windows это dll файлы, которые кладутся в папку к PHP и прописываются в конфиг php.ini). Более того, под Windows часть расширений идет в комплекте с PHP, надо только включить их загрузку в php.ini.

А если расширение малоизветсное, то придется собирать вручную, то есть идти тяжелым путем.

Теперь объясню фразу

> Для того, чтобы включить поддержку PostgreSQL необходимо скомпилировать PHP с директивой --with-pgsql[=DIR]

Исходный код расширения postgres включен в состав PHP и его не надо скачивать отдельно, достаточно при конфигурации сборки включить одну опцию. Если ты скачал скопилированный PHP, то скорее всего это расширение входит в его состав, и следующее предложение говорит об этом: "Если доступен динамический модуль, то он может быть включен директивой extension в php.ini, либо функцией dl()."

Тебе надо проверить что есть нужная dll (php_pgsql.dll) и прописать ее в php.ini.

Под Дебианом популярные расширения ставятся через apt-get, непопулярные компилируются утилитой pecl (вообще, там установка и сборка намного проще чем под виндой).

> установочная директория - папка, где все файлы, связанные с postgresql лежат, или путь к папке с .exe, который как бе и есть сам сервер?

Имеется в виду директория, где лежат заголовки postgres (заголовки - headers - это специальные исходные коды, которые позволяют исходному коду PHP узнать, как правильно вызывать функции из кода postgres. Если ты хочешь чтобы твой код мог вызывать методы сторонней библиотеки, тебе нужен либо полный исходный код этой библиотеки, либо скомпилированная библиотека + заголовки, описывающие имеющиеся в ней функции).

> Алсо, сейчас хостую демонстрационный сайт через XAMPP. Хватит ли мне его, чтобы взаимодействовать с PostgreSQL, или нужно ставить специально сконфигурированный под него апач?

Да, это вообще не важно, ты можешь даже использовать для разработки встроенный в PHP веб-сервер. Конфигурировать надо не веб-сервер, а PHP.

>>900769

Если давно не использовал, стоит повторить теорию? Есть глава (не очень хорошая) в моем учебнике в ОП посте, есть мануал http://php.net/manual/ru/pcre.pattern.php

>>900525

Смысл есть, но я бы советовал еще глянуть задачи на HTML из ОП поста - чтобы проверить, чему в итоге ты научился.

>>900367

Есть разные варианты:

- просто прописать пути в шаблонах
- сделать простой класс ResourceManager, в который в контроллере мы добавляем пути и позже в шаблоне генерируем теги link/script
- пойти хардкорным путем, определять нужные скрипты/стили в шаблоне и как-то их сканировать/анализировать чтобы знать, кому что нужно. Если используется шаблонизатор, можно ввести свои теги вроде {{ require-script 'news.js' }}. Ведь этот скрипт нужен для элементов в шаблоне и логично там и прописывать зависимость от него, где он нужен.
- твой вариант с конфигом

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

Надо учесть такие вещи:

- иногда надо подключить файл с стороннего домена (вроде google analytics)
- сторонние библиотеки обычно устанавливают копированием папки, и в ней есть свои подпапки вроде js/css

> ИМЯ_ШАБЛОНА(layout), ВИД_ПОДКЛЮЧЕНИЯ (CSS, JS и т.д.),

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

> Сам же метод надо будет вызывать в каждом layout, достаточно просто вызывать его не передавая никаких параметров, он уже сам будет решать куда что подключить, при помощи перебора свойств, если например КСС то вверх, если JS то в футер.

Подключение JS в футере имеет недостатки:

- нельзя вызывать JS функции в теле страницы из тега script
- пока футер не загрузится, все JS-кнопки не работают, так как не определена прописанная в их обработчике функция (или даже обработчик еще не повешен)

Ты наверно где-то увидел, что подключают JS в футере, и бездумно решил это скопировать. Зря. Надо проанализировать как преимущества, так и недостатки такого подхода. А ведь 99% просто копируют то, что делают популярные разработчики, а например мое мнение, которое им противоречит, почему-то никого не интересует. Такая вот у нас среда, вредные идеи хорошо распространяются среди малограмотных масс.

Мне например нравится когда JS файлы содержат только функции или классы и ничего не делают сами, пока мы не вызовем какую-то функцию. Но фронтендщики все как один пишут в них код вроде

$(document).ready(function() { инициализация })

А в чем проблема? А в том, что по мере развития сайта никто не удаляет старый код инициализации, и он только растет, более того, он запускается на каждой странице, даже если нужен только на одной. Я такое видел много раз. Этот подход с document.ready годится для сайта из нескольких страниц, а не для блоьшого развивающегося портала, но глупые верстальщитки везде как один копируют этот подход.

По моему это все пошло с моды на "unobtrusive javascript", описанный много лет назад в какой-то статье вроде такой:

- (англ) http://alistapart.com/article/behavioralseparation
- https://habrahabr.ru/post/25991/
- https://en.wikipedia.org/wiki/Unobtrusive_JavaScript

Сами-то идеи хорошие, но верстальщики уяснили из них ровно 2 вещи:

- активные элементы надо помечать классами
- в JS коде надо написать $(document).ready, ищущий элементы с этими классами и вешающий на них события.

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

Хуже того, иногда эти скрипты по document.ready меняют что-то в верстке, и верстка прыгает по этому событию. Это вообще ужасно.

То есть я хочу сказать, что надо:

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

Вот тут например человек тоже подозревает, что не все так хорошо: https://www.codeproject.com/articles/410948/how-jquery-and-unobtrusive-javascript-can-be-poiso

>>901672

Они тебе с вероянтностью 99% и не нужны. Паттерны же используют не просто так, а дял какой-то цели.

Например фабрику для таких целей:

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

- если нам надо создавать однотипные объекты на основе какого-нибудь конфига. Ну например у нас есть XML-файл с описанием формы и полей в ней, мы пропускаем его через фабрику и получаем соответствующие элементам формы объекты

Ну то есть не очень часто встречающиеся задачи.

У меня пока много других тем, которые надо осветить, и эта не самая важная.

У меня есть уроки по DI и по паттернам работы с БД:

- https://github.com/codedokode/pasta/blob/master/arch/di.md
- https://github.com/codedokode/pasta/blob/master/db/patterns-oop.md

Есть книга Фаулера, тут отрывки из нее: http://design-pattern.ru/

Есть сайт, дающий код реализации паттернов, но особо не объясняющий когда они нужны: http://designpatternsphp.readthedocs.io/ru/latest/README.html

Могу пока посоветовать изучить Симфони и ее компоненты (например, Формы, Доктрину), там многие паттерны использованы, и можно попробовать подумать, почему сделано именно так, а не иначе, как бы эту задачу решал ты.

Если ты не понимаешь Симфони, то за паттерны браться рановато. Нужен определенный опыт.

Если тебе это нужно для собеседования (что довольно глупо спрашивать, на мой взгляд, если в компании не используют фреймворк уровня Симфони), в интернете есть полно статей, выучи какой-нибудь синглтон, если собеседующий сам не знает паттерны (скорее всего так и есть), то он не сможет тебя завалить. Я бы конечно, если бы мне начали рассказывать про паттерны, спросил где их используют, какие преимущества, а в конце спросил бы, а не проще ли это сделать без паттерна, по-простому? И какой тогда смысл его использовать?

По алгоритмам гугли "структуры данных и алогритмы". Есть книги, видеолекции,вот например: http://aliev.me/runestone/

В алгоритмах самое важное это уметь оценивать их сложность по времени и по памяти, (я тут немного написал: http://arhivach.org/thread/216627/#898481 ) . При изучении структур данных желательно иметь представление о том как устроена память компьютера (это набор пронумерованных 1-байтовых ячеек) и исходя из этого ты может быть например поймешь сильные и слабые стороны вектора и связанного списка. Если не поймешь - спрашивай.

Изучи векторы, связные списки, очереди, стеки, деревья, графы, хеш-таблицы (словари) для начала.

Самая большая (гигантская) книга по алгоритмам - это Кнут, "Искусство программирования". Ее тебе изучать лет 10 наверно придется. Там только про одни генераторы случайных чисел огромная глава.

>>900113

Что для тебя эффективность? Стоимость труда? Потребление памяти? Поддержка Windows? Наличие популярных CMS?

>>900050

> echo "Не удалось создать сокет, причина: " . socket_strerror(socket_last_error()) . "\n";

> die;

Прочти уже урок про исключения, если знаешь ООП: https://github.com/codedokode/pasta/blob/master/php/exceptions.md

У тебя есть проблема в том, что ошибка не передается из socketWrite выше. Ты пишешь в консоль, закрываешь сокет, но вызывающий код об этом не знает и пытается дальше использовать этот закрытый сокет. Неправильно.

> $buf = trim($buf);

> ...

> if (preg_match('/\n/', $buf)) {

trim удаляет \n с краев и preg_match сработает только если он был в середине пакета данных. Странная логика, не находишь?

Я просил сделать следующее: функцию-генератор, которая при каждой иерации возвращает 1 строку из пришедших данных. Так как данные приходят пакетами незвестного размера, то может быть 1 пакет с несколькими строками, может быть несколько пакетов с 1 строкой. И при таком подходе нам нужен внутренний буфер для накопления данных. И удобнее всего это делать генератором. Вот алгоритм:

буфер = '';
вечный цикл {
- читаем пакет данных;
- проверяем ошибки;
- проверяем, не закрыл ли отправитель сокет, если да, то выплевываем остаток буфера, если там что-то есть и выходим;
- кладем пакет в буфер
- пока буфер содержит символ \n, цикл {
- вырезаем первую строку из буфера вместе с символом \n
- выплевываем ее
}
}

Вот примерно такая логика. Как видишь, без генератора обычной функцией реализовать такую логику сложно (разве что использовать глобальную переменную-буфер, но код будет гораздо запутаннее - можешь проверить и попробовать написать для сравнения, и из-за глобальной переменной нельзя работать более чем с 1 сокетом одновременно).

Генератор хорош тем, что позволяет как бы выполнять 2 цикла (цикл приема данных из сокета внутри функции и цикл генерации ответа на строку), переключаясь между ними с помощью yield.

Твой генератор работает как-то криво и через раз.

> там в следующей задаче написано про многопоточность, я что-то не нашел ничего внятного про многопоточность на пхп, только открытие нескольких процессов вручную (зачем?).

Многопоточность здесь значит возможность обрабатывать несколько потоков данных одновременно. Твой echo сервер например в один момент времени работает только с одним потоком: либо ждет пока пакет отправится, либо пишет в консоль, либо ждет пока пакет придет, либо ждет нового соединения. Это сильно нас ограничивает. Для чата даже из 2 человек нужна многопоточность, так сервер должен ждать входящее сообщение на 2 сокетах сразу. И отправлять 2 людям, не зависая если кто-то из них не принимает пакеты.

Реализовать многопоточность можно по-разному, вот мой урок: https://gist.github.com/codedokode/ffd520440a970c07c1c6

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

- делаем операции на сокетах неблокирующими
- используем socket_select, чтобы ожидать событий на нескольких сокетах сразу
- как только произойдет какое-то событие (пришли новые данные, сокет готов к передаче новой порции данных) - обрабатываем это событие и снова вызваем socket_select в ожидании следюущего.

То есть освой работу с неблокирующими сокетами и socket_select.

Имей в виду что socket_select неэффективен при большом числе сокетов (десятки, сотни). Для них нужно что-то вроде libevent. Но ты пока об этом не беспокойся, у тебя их так много не будет.

В клиенте-загрузчике тут while (false !== ($out = socket_read($socket, 2048))) нет проверки, почему вернулся false - это ошибка или просто соединение закрыто сервером.

> $response = preg_split('/\r\n\r\n/', $response, 2)[1];

Тут ты предполагаешь что в ответе сервера есть эта последовательнсоть. Но что если он выдал ошибочный ответ? Также, советую сделать \r необязательным, чтобы работала и просто \n\n - так надежнее.

>>899904

> в её конструкторе заполняют pdo через синглетон, который находится в специальном отдельном классе Db.

Это плохая идея, почитай урок про DI: https://github.com/codedokode/pasta/blob/master/arch/di.md

> Далее в основной моделе описывают методы для работы с БД, типо findAll, findOne

Это просто класс для работы с базой данных. На практике тебе не нужны методы вроде findAll, а нужны getLatestNews, getNewsByYear и так далее.

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

Либо сделать в "модели" дополнительные методы с бизнем-логикой, либо сделать слой классов-сервисов с бизнес-логикой, которые для работы с БД используют класс работы с БД.

Вообще, ты плохо понял MVC если думаешь:

- что модель это один класс или набор однотипных классов
- что назначение модели лишь работать с БД

Вот рассмотрим регистрацию пользователя. Что тут задача контроллера, а что модели? Задача контроллера это:

- принять данные из запроса
- попросить модель проверить их
- попросить модель зарегистрировать нового пользователя
- залогинить нового плоьзователя

Задача модели:

- проверка данных нового пользователя
- создание нужных записей в БД, их может быть больше одной если например данные хранятся в нескольких таблицах
- дополнительные задачи, вроде отправки письма подтверждения email

Потому модель может состоять из разных классов-сервисов.

Проверить, насколько верно у тебя реализовано разделение логики можно, попробовав написать альтернативный контроллер. Например, скрипт регистрации пользователя, который запускается из командной строки и должен либо вывести id нового пользователя либо сообщение об ошибке в данных. Или можно попробовать заменить хранение данных в базе на хранение в файле. Придется ли что-то менять, кроме модели?

Вообще, ты решал нашу задачу про студентов? Там многие такие вопросы разбираются.

> Создать в модели дополнительные свойства, в которых хранить определённые результаты манипуляция и получить к ним доступ из контроллера?

Не надо. Функция должна возвращать результат через return, а не обходным способом.

> class Main extends Application {

Странные названия. Main - это контроллер? А что такое Application?

> //передаём переменные в вид

> $this->set("posts", "title_post");

Странно, ты передаешь данные в вид, но метод вызываешь на контроллере. Зачем тут посредник и почему нельзя передать данные напрямую?

> Меня в общем смущает, что в контроллере будет много кода, а в моделе его практически не будет вообще

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

Ты кстати этот урок читал? https://github.com/codedokode/pasta/blob/master/arch/mvc.md

Там есть пример кода.

Как заставить новости отображаться в обратном порядке, то есть так:
"тест 3"
"тест 2"
"тест 1"

Вот сам код

<?php

$dsn = "mysql:host=$host;dbname=$db;";
$opt = array(
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC);

$pdo = new PDO($dsn, $user, $password, $opt)
?>
<?php
$stmt = $pdo->query('SELECT * FROM news');
while ($row = $stmt->fetch())
{
printf('
<h2><img width="191" height="127" class="igm" src="%s"><p class="data">%s<p class="text">&nbsp&nbsp&nbsp&nbsp&nbsp%s</p>
<a href="%s"><img class="ss" src="images/ss.png"></a></h2>
',$row["photo"],$row["date"],$row["text"],$row["link"]);
}
?>

ОПу привет и с нг (я где-то полгода назад активно учился в треде, так что хотел сказать спасибо за помощь).

На работе достаточно много свободного времени (как впрочем и дома), поэтому возвращаюсь к учебе.
В планах повысить навыки: git (очень важно), подтянуть js/верстку, а также доделать testhub (когда-то начал, но забросил).

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

Рассказываю такой пример из практики:
Есть большой сайт/сервис. Решили сделать его клон с немного другим функционалом, дизайном и сео-направленностью.
(Кстати обсуждали вопрос по синхронизации бд, в итоге решили просто перезаливать дампы по крону, но я думаю что есть явно
более интересные способы решения этой задачи, скиньте почитать по этой теме).
Проблема так же в том, как синхронизировать изменения в системе контроля версий? На главном сайте один программист пофиксил
баг. Как мне перенести изменения на клонированный сайт? Пока с трудом (сейчас расскажу подробнее почему с трудом) смог вытянуть изменения
через git diff, но что-то мне подсказывает, что делаю что-то не так.

Так вот, каждый программист работает с отдельной версией сайта (папочки dev1, dev2, и т.д.), но гит-репозитории создаются либо локальные
(на рабочем компьютере программиста), либо на удаленном сервере, это зависит от того, как настроена ide.
Я работаю например с версией dev1, захожу через ssh и там уже работаю с гитом через командную строку. То есть мой нетбинс синхронизирует файлы
с сервером, но с гитом я работаю напрямую.
Чувак работает через PhpStorm, у него репозиторий на своем компе. Соответственно я не могу зайти к нему в папку dev2 на сервере
и посмотреть лог и дифф, как делаю в своей папке.
Продакшн в папке prod, в нем только мастер, который сливается раз в месяц.
Центральный репозиторий (откуда я вытягиваю изменения, и куду пушу, то есть тот который remote -v) в папке git.
Но в этой папке нет рабочих файлов, там внутренности гита (branches, HEAD, config и т.д.), соответственно я могу посмотреть разве что
git log на текущей ветке master, но не могу переключиться на другую ветку и посмотреть в ней историю, пишет
fatal: This operation must be run in a work tree

Решил проблему через жопу, через клонирование центрального репозитория себе на комп во временную папку
git remote add -t target_branch origin ssh://...
git checkout -b target_branch
git pull origin target_branch

В общем, нужно подтягивать знание гита, реквестирую интересные мануалы типа задач от опа (новых задач кстати не появлялось
за последние полгода?).

>>902481

В одном проекте я видел такое решение: используется общий код для 2 проектов, при этом View (и JS/CSS) и Controller у каждого свои, а Model и БД - общая. Ну и естественно во многих местах ифы (если это проект1, то делать так, а если проект2, то иначе) натыканы. В БД также некоторые поля в 2 копиях (показывать страницу на проекте1, показывать на проекте2).

Даже если использовать 2 разных БД, все равно с общим кодом наверно было бы удобнее работать.

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

Идея сделать отдельный независимый репозиторий, в общем плохая. Замучаешься переносить изменения, и этот процесс невозможно автоматизировать, так как код может понадобиться адаптировать при переносе. Если будешь гуглить, это называется "port patches", портирование измененей в несвязанных друг с другом репозиториях.

Я бы советовал найти кого-нибудь, на кого можно переложить портирование изменений, это ручная не автоматизируемая на 100% работа.

В гите есть ветки, теоретически можно было бы вести 2 проекта в 2 ветках, но я ни разу с таким не сталкивался, и уверен, что будут какие-то сложности. Ветки все же предназначены для того, чтобы добавлять какие-то новые фичи, а не делать отдельный проект. Хотя гит позволяет, используя cherry-pick вместо merge выбирать, какие изменения перенести.

Также, теоретически, можно было бы попробовать разбить код проекта на уникальную часть и общую, и общую часть (части) вынести в отдельные библиотеки, которые подключаются в проекте1 и проекте2. Но это по сути усложненная вариация первого подхода.

Еще, я знаю, вордпресс позволяет вести несколько сайтов, но там по моему код общий, просто у каждого сайта своя копия БД. То есть тебе не очень подойдет.

Теперь насчет переноса изменений. Такая потребность часто бывает, ну например при обнаружении бага в Windows 10 майкрософт вынужден патчить и более старые ОС, как я понимаю, там вручную переносят и адаптируют патч под каждую ОС.

Ты можешь попробовать такой подход. Сделать дифф изменений в проекте1 (получится так называемый патч), вручную исправить этот патч (убрав ненужное) и применить к проекту2.

https://git-scm.com/book/ru/v1/Распределённый-Git-Сопровождение-проекта

Там есть пункт про применение патчей, полученных по почте, может оно тебе подойдет?

Также, тут http://stackoverflow.com/questions/5120038/is-it-possible-to-cherry-pick-a-commit-from-another-git-repository/15421574#15421574 предлагают подключить второй репозиторий как удаленный, сделать fetch, но вместо merge (примерджить все изменения из него) использовать cherry-pick (отобрать вручную нужные изменения). Но тут проблема, что если ты нечаянно сделаешь pull то вмерджится все, то есть легко ошибиться.

Я сам, если честно, до такой степени в гите не разбираюсь. Но я понимаю, что гит в общем не рассчитан на работу с 2 независимыми репозиториями. Я бы не советовал тебе изучать все его тонкости, а только те команды, которые могут пригодиться в твоей задаче.

По синхронизации БД: лучше всего было иметь одну БД. Также, в MySQL есть репликация, аж 2 вида: statement-based (с мастера на слейв идет поток SQL запросов) и row-based (с мастера на слейв идет в бинарном виде содержимое изменившихся строк и ячеек).

> Так вот, каждый программист работает с отдельной версией сайта (папочки dev1, dev2, и т.д.), но гит-репозитории создаются либо локальные

(на рабочем компьютере программиста), либо на удаленном сервере, это зависит от того, как настроена ide.

Так эти репозитории связаны? Они создаются через git clone или разработчик тупо копипастт файлы и создает новый репозиторий из них?

Обычно делают так: есть центральный репозиторий. Разработчик делает git clone, получает копию. Потом периодически делает git pull, чтобы забрать новые изменения от других людей. Когда надо что-то добавить в код, он создает ветку, пишет код в ней, пушит в центральный репозиторий и отправляет старшему на проверку. Тот смотрит, если все ок, мерджит его в мастер.

Иногда работают без веток, разработчик сразу пушит в мастер, если люди ответственные и внимательные то так тоже можно.

Из твоего описания я не понял, как это устроено у вас.

Тебе советую перечитать про удаленные репозитории и ветки, команды git branch, git pull/push. Что-то у меня ощущение, что ты плохо понимаешь, как все устроено.

Попробую немного пояснить.

Коммит - это набор всех файлов + дополнительная информация (вроде комментария, автора и тд). То есть когда ты делаешь коммит, гит, условно говоря, создает копию всех твоих файлов и сохраняет ее в папочку .git. разумеется, там все по-умному оптимизировано и сжато и при коммите репозиторий не увеличивается в 2 раза.

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

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

push работает так: он сравнивает список коммитов в локальной ветке и удаленной ветке с тем же именем и отправляет коммиты, которых нет на удаленном сервере. Если удаленно такой ветки нет - она там создается.

pull работает так: делает fetch изменений с удаленного сервера, затем merge.

fetch сравнивает список коммитов локально и удаленно в текущей ветке и скачивает отстутсвующие локально коммиты в origin/master. Ты можешь далее вмерджить их к себе в master.

Не понимаю, зачем тебе лезть в личные репозитории других разработчиков. Если тебе нужен код, который есть у них, но нет в центральном репозитории, есть 2 варианта:

- попроси их поместить код в отдельную ветку и запушить в центральный репозиторий
- подключи их репозиторий как удаленный (git remote add) например под именем dev2 и с помощью git fetch dev2 master ты скачаешь коммиты того разработичка в локальную ветку dev2/master, где можешь их просмотреть или смерджить.

Сделать git remote add можно только если репозиторий удаленно доступен по какому-то протоколу.

> Центральный репозиторий (откуда я вытягиваю изменения, и куду пушу, то есть тот который remote -v) в папке git.

Но в этой папке нет рабочих файлов, там внутренности гита (branches, HEAD, config и т.д.), соответственно я могу посмотреть разве что

> git log на текущей ветке master, но не могу переключиться на другую ветку и посмотреть в ней историю, пишет

Это репозиторий без рабочей копии, то есть используется просто как хранилище кода (коммитов) и состоит из папки .git. зачем тебе в нем что-то смотреть? Ты делаешь fetch/pull и получаешь все изменения из него к себе.

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

>>902482

> Расскажи как устраивался

Просто взял и устроился без левых мыслей.

> с каким багажом

Хорошим (по сравнению с другими "соискателями") багажом по php: написал оповский файлообменник с 95% поставленных багфиксов, поверхностно изучил два фреймворка (юи и симфони). Слабыми по js. Отличными по sql. Верстка само собой.

> как проходили собеседования

Их должно быть больше одного?
Чувак по скайпу минут пять примитивщину по теории (неймспейсы, замыкания, отличия между версиями php, внешние ключи, виды джойнов, движки mysql, нормализация, транзакции, области видимости в js, доктайп и т.п.).

> кем взяли?

Веб-разработчиком.

> помотивируй

Понятия не имею, кто ты и какие у тебя цели.
У меня была цель уехать из ненавистной мухосрани в культурный красивый город (который меня впрочем успел достать шумом и суетой в метро).
Теперь хочу а) уютный домик в тихом пригороде б) карьерный рост как показатель прокачки моего irl персонажа.
Умную бабу еще хочу, но тут придется обломиться наверное.

>>902687

> используется общий код для 2 проектов, при этом View (и JS/CSS) и Controller у каждого свои, а Model и БД - общая

Это пожалуй был бы оптимальный вариант. Вообще я спрашиваю чисто для себя, для будущего опыта.
На практике проект в таком состоянии, что действительно остается махнуть рукой и вносить вручную все изменения параллельно в обе версии.
Бд спроектирована плохо, и для некоторых таблиц должны быть разные данные, заполняемые каждая из своей админки. Вернее часть полей общая, часть конфликтующая между проектами. То есть нужно переделывать структуру бд. Код сильно завязан на структуру базы, придется много переписывать.
Ну и нет уверенности, что проекты будут в дальнейшем синхронизироваться, скорее всего на втором сайте будет добавляться новый функционал, старый убираться.

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

> Ты можешь попробовать такой подход. Сделать дифф изменений в проекте1 (получится так называемый патч), вручную исправить этот патч (убрав ненужное) и применить к проекту2.

Да, я же и пошел таким путем. Хотя запутался в репозиториях и ветках.
Про cherry-pick (видимо речь про вишенку с торта, считающуюся почему-то лакомством) слышал, но не знал что можно переносить коммиты между репозиториями.

По гиту основы знаю (пуш, пулл, коммит), но с ветками и работой с удаленными репозиториями пока слабо.

> Коммит нельзя отредактировать, но можно удалить и закоммитить заново, при этом у него может поменяться хеш.

--amend по-моему, но это только для последнего коммита, насчет удаления коммитов из "средины" истории даже не знаю, хотя наверное это не часто на практике

> То есть когда ты делаешь коммит, гит, условно говоря, создает копию всех твоих файлов и сохраняет ее в папочку .git

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

>The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes.

> if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.

https://git-scm.com/book/en/v2/Getting-Started-Git-Basics
Я если честно плохо понимаю, что такое "снимки" (snapshots), чем они отличаются от "list of file-based changes".
Кажется, суть в том, что другие скв хранят именно диффы для каждого файла, а гит рассматривает папку как "a miniature filesystem". Как будто я знаю принципы работы файловых систем и мне это о чем-то говорит.
Короче, не знаю почему они делают такой акцент на этом, и как это может пригодиться на практике.

############################################
По поводу того как у нас организована работа с гитом. Мне конечно сложно объяснить, потому что сам плохо понимаю, но попробую.
На удаленном сервере (где-то во Франкфурте) есть папочка /var/www/sites/project1

В ней список директорий
1) prod - папка продакшн, в ней есть репозиторий, но только с веткой master. В нее пушит тимлид когда сделает ревью по внесенным правкам. То есть я не могу зайти в папку prod и посмотреть в ней диффы нужных мне изменений, их здесь еще нет. Это не центральный репозиторий. Центральный репозиторий - в папке git (см. пункт 3).
2) папки dev1, dev2, ... - копии проекта для каждого разработчика. У меня в папке dev1 есть репозиторий, я по ssh захожу в эту папку и из нее делаю пулл/пуш в центральный репозиторий в папке git (см.пункт 3). В папке dev2 (коллеги) есть рабочая копия проекта, но нет репозитория, потому что он прямо со своей машины пушит в папку git (смотри пункт 3)
3) git (без точки) это папка, из которой я и другие разработчики тянут изменения, и куда все пушат изменения. То есть в своем репозитории я выполню git remote -v, выведет /var/www/sites/project1/git
Таким образом только здесь есть все ветки, в том числе нужная мне target_branch, где есть искомый коммит. Но я не могу посмотреть эти изменения прямо в репозитории (или не знаю как).
Спуллить не могу, потому что полезет туча конфлик... А, все, понял ошибку, я забыл что кроме пулла есть фетч. Вернее о существовании знал, но не употреблял на практике.
Вот вам и голая теория без упражнений.

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

От вас хрен дождешься годноты, что-то сам нагуглил.
https://githowto.com/ru
Сейчас проверю, хотя там скорее всего пять хелловорлдов а потом просьба где-то зарегистрироваться и что-то купить.
Вот еще что-то http://rypress.com/tutorials/git/index

>>902806

хеш коммита определяется из хеша файлов и метаданных (включая время). --amend по сут создает новый коммит с новым хешем.

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

Это уже детали и оптимизации. Есть другой подход, когда мы сохраняем начальное состояние, а потом в каждом коммите сохраняем изменения (diff, patch) в сравнении с предыдущим. Нетрудно написать на bash такую примитивную систему управления версиям.

Гит так не делает, он к каждому коммиту прикрепляет все файлы из рабочей области. Ну а дальше уже идут оптимизации: информация о файлах записывается в виде хешей (по которому в хранилище можно найти тело файла), и если файл не поменялся, то его хеш остается неизменным и новый объект в БД не добавляется.

Вообще, гит построен вокруг хешей. Хеши являются идентификаторами для содержимого файлов, коммитов и других объектов внутри хранилища (хранилище - громко сказано, оно реализовано как папки с файлами внутри .git/objects).

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

Кстати, ветки - это файлики в .git/refs/heads, которые содержат хеш "головы", последнего коммита ветки. Остальные коммиты ищутся благодаря тому, что в каждом коммите есть хеш родительского коммита.

> Я если честно плохо понимаю, что такое "снимки" (snapshots), чем они отличаются от "list of file-based changes".

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

diff это когда ты при коммите сравниваешь текущее состояние с предыдущим и сохраняешь разницу между ними.

А дальшу уже идут оптимизации: гит вместо сохранения самих файлов каждый раз сохраняет в коммите их хеши, и добавляет те, которых там еще нет, в хранилище. Если файл не изменился то у него тот же самый хеш и он второй раз в хранилище не добавляется.

То есть там такой алгоритм коммита (я упрощаю конечно):

- взять хеши всех файлов
- добавить каждый в хранилище, если там нет файла с таким хешем
- записать все хеши в объект коммита
- сгенерировать хеш от коммита и записать сам объект коммита в хранилище под этим хешем
- записать в указатель на "голову" текущей ветки хеш нового коммита

На самом деле там все еще немного сложнее, там в коммит записывается не просто список всех хешей файлов, а ссылка (хеш) объекта tree, который как бы соответствует папке. Но это уже детали.

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

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

> prod - папка продакшн, в ней есть репозиторий, но только с веткой master. В нее пушит тимлид когда сделает ревью по внесенным правкам.

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

> папки dev1, dev2, ... - копии проекта для каждого разработчика.

Ну это уже получается личное дело разработчика, как туда помещать файлы. Тебе к ним лезть незачем.

> Таким образом только здесь есть все ветки, в том числе нужная мне target_branch, где есть искомый коммит. Но я не могу посмотреть эти изменения прямо в репозитории (или не знаю как).

Тебе надо скачать нужные ветки к себе и смотреть у себя. pull ты делать не обязан, для просмотра хватит и fetch.

> Спуллить не могу, потому что полезет туча конфлик

Ну это потому что ты пуллишь удаленный мастер в свой. Но ты мог бы пуллить или фетчить именно нужную ветку оттуда и конфликтов не будет, если ты ничего не коммитил в нее. В origin/branch не коммитят и потому fetch не вызывает конфликтов.

fetch копирует новый коммиты из удаленной ветки branch в origin/branch у тебя. А pull дополнительно мерджит origin/branch в локальный branch.

origin/branch - это как бы локальная копия удаленной ветки

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

>>885216 | http://arhivach.org/thread/216627/#885216

Тут можно было конечно сделать чуть оптимальнее - вместо пары методов generateDayPower/consumeDayPower сделать один метод, который возвращает положительное или отрицательное значение (вклад в баланс). Это позволило бы сократить код.

> function PowerStation() {

> PowerNetElement.apply(this, arguments);

как я помню, у электростанции мощность всегда одинакова и потому тут в конструкторе должен быть 1 аргумент.

Аналогично, у SolarPanel должен быть 1 аргумент - дневная мощность, у дома - число квартир, и тд.

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

Насчет линии электропередач - если она наследуется от элемента сети, стоило все же вызвать его конструктор, указав 0 в качестве мощности.

> @param {(PowerElement|PowerStation|SolarPanel|House|PowerLine)}

Можно просто писать название базового класса.

> var tmpNetElements = this._netElements.filter(function(element)

> return ! ("getTransmittedPower" in element);

Я думаю, для отсеивания линий передач лучше было бы проверять конструктор через instanceof PowerLine, либо сделать в PowerNetElement метод isPowerline. Первое наверно проще.

> if (instockPower >= demandPower - power) {

> } else {

Тут стоило применить Math.min или max вместо if.

> 'purchaseCost': purchaseCost + ' тугр.',

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

> if (typeof(report[key]) == "number") {

> report[key] = Util.convertkWToMW(report[key]);

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

Всех анонов с наступающим!

http://arhivach.org/thread/216627/#898482
Исправленные задачи:
Угол между стрелками: http://ideone.com/4KXN1O

Вывод знака зодиака: http://ideone.com/Fg7RMI

> Насчет поиска знака зодиака, я думаю, проще было сделать массив вида ['Козерог', 21, 1] и сравнивать числа, не перекодируя их в даты.

Тогда и номер месяца можно убрать, если его можно получить из индекса знака зодиака в массиве? Это позволило избавится от цикла и сразу по индексу обращаться к нужному подмассиву с информацией о знаке зодиака. А дальше проверка: если номер дня на входе больше, чем номер дня в подмассиве - отдаём этот знак, если номер дня на входе меньше - отдаём предыдущий знак.

Дерево

> Также, можно написать код без объектов Node и рекурсии, используя стек (стек для хранения записей, которые мы позже выведем, после того как разберемся с их детьми).

Подход без рекурсии на базе стека действительно оказался простым: https://jsfiddle.net/0gpbzo8y/
но не совсем понятно, как выводить список вложенным, а не просто показывать список посещённых элементов. Сделал очень костыльно с добавлением ключа depth к каждому элементу массива: https://jsfiddle.net/0gpbzo8y/2/

Алсо я вспомнил про задачу на джуна, которую тут вбрасывали пару тредов назад, приложил скрин к посту. Как правильно реализовать третью часть? На запрос вида /catalog/samsung/s7 мне нужно выдавать товар, у которого path = s7, path родителя samsung, path его родителя = catalog. Я додумался только до того, чтобы генерировать вложенный sql-запрос. Например, для запроса /catalog/dvd/lg будет генерироваться такой:
select * from items where path = 'lg' and parent_id = (
__select id from items where path = 'dvd' and parent_id = (
____select id from items where path = 'catalog'
__)
);
Это очень плохое решение? Запрос генерирую так: http://ideone.com/pTS09b

Дом 2
https://jsfiddle.net/je858mz4/5/

N рабочих дней

> Автоматически рассчитать даты праздников, увы, нельзя, так как их переносят из-за выходных.

Я понял. Допустим, я получил, неважно как, список всех нерабочих дней в виде массива элементов вида 'd-m-y', решение будет примерно таким http://ideone.com/go0Mfo ?

Про алгоритмическую сложность отпишу отдельно, спасибо большое за ответ!

http://pastebin.ru/yLh80hF8

>11. дан список вида «страна, город, население»

>https://jsfiddle.net/50cncv5L/

https://jsfiddle.net/50cncv5L/1/

>12. Некая сеть фастфудов предлагает несколько видов гамбургеров

>https://jsfiddle.net/y28h2o2b/

https://jsfiddle.net/y28h2o2b/2/

>13. В одном городе есть электрическая сеть. К ней могут быть подключены

>https://jsfiddle.net/6591a2sL/

https://jsfiddle.net/6591a2sL/3/

>> someTypeOfSolarPanel.prototype = Object.create(SolarPanele.prototype);

>ты тут делаешь наследование, но тогда хорошо бы в someTypeOfSolarPanel() вызывать конструктор класса-предка. А то кто-то допишет в него код (или модифицирует), а потом будет гадать, почему этот код не срабатывает в наслднике. Если нет каких-то причин не делать этого, то стоит вызвать конструктор предка. То есть конструктор предка заполняет нужные ему поля, конструктор наследника - нужные наследнику.

Я предпологал что отдельный тип панели, это тот в котором "железно" определена мощность. Если этой причины не достаточно, то я просто переопределю конструктор класса-предка написав:

function someTypeOfSolarPanel(power) {
SolarPanele.apply(this, arguments);
}

>> for (var element in electricalnetwork.elements) {

>> if (electricalnetwork.elements[element] instanceof PowerLine) {

>Если делать это циклом то нет гарантии что мы продадим энергию по максимальной цене. Лучше отсортировать предложения по выгодности и продавать начиная с самой дорогой линии.

Теперь можно написать программу по расчету самого выгодного предложения. Линия электропередач может посчитать какую сумму можно получить за определенное количество ватт PowerLine.countPrice(power), учитывая свою пропускную способность. Осталось только поместить эти данные в массив и отсортировать его.
Но не будет ли это уже другой задачей?

У меня, кстати, есть решение по которому я сначала делал эту задачу, где происхдоит "имитация" торговли: https://jsfiddle.net/qvdz8y5j/
Такой вариант задачи мне нравится больше, потому что мы не просто считаем возможные варианты прибыли\мощностей, а действительно меняем систему.

>14. напиши функцию, определяющую тип переменной. Результат должен быть одной из строк: 'undefined', 'boolean' (для true/false), 'null', 'number', 'string', 'function', 'array', 'array-like', 'object'

>https://jsfiddle.net/5q3r473h/

https://jsfiddle.net/5q3r473h/3/

>15. Напиши функцию неглубокого копирования объектов и массивов

>https://jsfiddle.net/uyey3at1/

>> var clone = new object.constructor;

>Тут есть подвох: JS не гарантирует что свойство хранит ссылку на фукнцию-конструктор. Оно хранит ее по умолчанию, но разработчик может перезапистаь его, а также забыть правильно прописать его при наследовании. Ну я думаю, что это можно оставить, но стоит помнить про такие вещи. В самой задаче копировать до такой степени не требовалось.

Значит в js нету универсального решения чтобы получить имя класса - нужно писать самому под каждый отдельный случай?

>> for (property in object) {

>Ты склонируешь не только свойства объекта, но и всех его прототипов. если у объект в прототипе есть метод, он будет перебран в этом цикле (у встроенных в JS объектов вроде массивов методы защтщены от этого и не перебираются циклом, а у пользовательских классов перебираются).

Так это же хорошо что клонируется и прототип объекта, разве нет? Я думал, что прототип, это что-то, что принадлежит каждому образцу класса\объекта. Разве это не нужно клонировать?

>16. Напиши функцию глубокого копирования объектов и массивов

>https://jsfiddle.net/j8pydqsg/

https://jsfiddle.net/j8pydqsg/1/