С Packagist будет совсем не так. Во-первых там каждый вендор имеет свой неймспейс, и вопросов про права на названия пакетов просто не возникнет. Во-вторых там нет пакетов, обрабатывающих один кошачий чих. Есть обрабатывающие пять-шесть чихов, но другие серьёзные пакеты от них не зависят. Ну и если кто-то что-то оттуда выпилит — никто другой на его место через 10 минут своё не впилит (см. про неймспейс).
Роуты вообще должны генерироваться из RAML, окститесь. Middleware разменивают условную скорость (50ms или 60ms?) на удобство разработки и читаемость кода, ну и по уму их надо, конечно, подключать в правильном порядке. Вебсокеты, консоли, универсальные адаптеры и прочие разделы из CS 102 оставьте студентам. Люди, делающие реальные проекты и зарабатывающие себе этим на жизнь, только устало улыбнутся.
Только вы не учли, что в аэропорт Антальи к 7 утра придется ехать на такси вместо Havas, в Ататюрк из Стамбула к 6 утра — тоже, а такси в Турции очень дорогое. Думаю только эти два пункта сведут на нет разницу в цене, а ещё надо где-то в Стамбуле переночевать, и из Сабихи Гёкчен добраться до города и там до отеля, скорее всего комбинацией Havas + метро, что займёт часа полтора. То, что надо после подъема в 5 утра, чтобы успеть на самолёт в 7.
Дефолтный middleware от Slim в случае невалидного JSON просто молча обнуляет переменную $env['input'], перенося исходный в переменную $env['input_original']. Можно по этому факту понять, что что-то пошло не так, а можно в несколько строк унаследовать от дефолтного свой middleware, с валидацией и эксепшенами :)
Бизнес-логика, само собой, отправляется в контроллеры соответствующих сущностей, т.е. понятно, что никто не пишет весь REST инлайн-функциями, последняя строчка вживую выглядит скорее как:
Я это всё к тому, что PHP (в том числе к моему собственному удивлению) на сегодня эволюционировал в довольно пристойную экосистему, и не надо вот так через губу о нём свысока отзываться :) В активе у него — большая база разработчиков (я думаю, самая большая на сегодня, JS ещё пару лет догонять), удобный в освоении синтаксис "для ленивых" (чего стоит, например, разрешённая запятая после последнего элемента массива), множество вшитых быстрых функций для работы с актуальными для веба данными (всякие array_merge, array_column), отличный менеджер пакетов Composer и репозиторий Packagist для него, в отличие от Node не хранящий в себе всякий однострочный шлак (см. анекдот про left-pad).
Ну и над всем этим — open-source фреймворки (Laravel, Symfony) и CMS (Drupal и WordPress) с колоссальной накопленной базой кода и готовых решений. Так что если надо сегодня делать что-то, чему надо быстро взлететь, лихорадочно расти и начать приносить доход — я пожелаю удачи любителям Go, Erlang, F# и что там ещё придумали в последние годы, а сам буду набирать команду на PHP.
у явы как ни странно сахара больше и кода для какого-нибудь реста писать надо порядочно меньше
require 'vendor/autoload.php'; // Slim + Eloquent + DB init via composer.json
$app = new Slim\Slim();
$app->add(new Slim\Middleware\ContentTypes()); // Parse application/json on request
$app->contentType('application/json;charset=utf-8'); // Return application/json on response
$app->get('/v1/users/:id/', function($id) {
return MyApp\Models\User::finOrFail($id)->toJSON();
});
Ещё меньше?
NB: это ещё я знаю толк в извращениях, скрестил когда-то ежа с ужом, Slim и Eloquent, и с тех пор ленюсь посмотреть на Lumen, для которого Eloquent родная ORM.
Мне статья вообще очень понравилась, не хотелось бы, чтобы у вас сложилось обратное мнение. Так что просто просто поделился опытом. Хотя вот у коллег ниже статистика другая.
Самое же прекрасное, что вы почему-то не упомянули, что в PHP7 нельзя использовать в качестве имени класса Error. А именно так назвать класс, унаследованный от Exception в PHP5, считает своим долгом в среднем каждый пятый разраб.
О своём опыте: перевёл пару проектов на WordPress, довольно плотно обвешанных плагинами и темами, под PHP7, разница в производительности впечатляет. 10-долларовый дроплет DigitalOcean отдаёт страницы за ~500ms (при правильной сборке и настройке nginx). Правда приходится регулярно ловить incompatibility issues в чужом коде. Особенно люто валятся всякие indirect references на функции или методы классов.
Поэтому проект и интересный. Получается, что тут узкое место — сканеры. Значит надо брать существующие и заставлять их работать в три смены 24 часа. Дальше отправлять насканированное на OCR, потом на верстку/сборку, потом на вычитку. Должен быть выстроен целый производственный процесс для этого, распределенный и масштабируемый.
Ссылку на список литературы на оцифровку я привёл, вы там нашли что-нибудь, что есть уже на Флибусте/Рутрекере?
При перепечатке с Роема в текст вкралась важная смысловая ошибка: список из 50-60 тысяч наименований не «есть у Литреса», а имеется готовый: «В список книги отбираются на основе спроса читателей в РГБ и Российской национальной библиотеке с учётом рекомендаций Совета по науке при Минкультуры, экспертных оценок Российского книжного союза и общественного обсуждения». Вот, собственно, этот список: www.rsl.ru/ru/s410/spisok
Хорошо, если что-то найдётся в уже более-менее готовом виде, и надо будет только отформатировать. Но скорее всего большинство книг придется сканировать с нуля, и цена в 8700 не кажется завышенной. Посчитайте хотя бы по зарплатам: допустим, что оператор-надомник стоит 40000 рублей (это предельно мало для Москвы) и цифрует 20 книг в месяц (выше по комментам есть несколько оценок в этом ключе), 60 книг за 3 месяца. Пусть цифровать надо 9000 (а 2000 найдутся готовые), значит операторов надо 150 человек и их ФОТ составит 18 миллионов. Налогов и взносов в фонды с этих денег надо будет заплатить ещё примерно 8 миллионов. Далее, редакторы-корректоры — пусть вдвое дешевле, а то развелось этих гуманитариев: ещё 13 миллионов ФОТ + НДФЛ + фонды. Верстальщики, которые в итоге готовые книжки соберут — всяко ещё миллионов 10. Юристы, бухгалтеры, менеджеры — ещё 10. Минус 18% НДС, остается 19 миллионов, или 20%, вполне умеренная маржа для нынешней России, где 20% в рубле за 3 месяца можно получить, просто купив швейцарские франки и положив их под матрас.
Дефолтный middleware от Slim в случае невалидного JSON просто молча обнуляет переменную $env['input'], перенося исходный в переменную $env['input_original']. Можно по этому факту понять, что что-то пошло не так, а можно в несколько строк унаследовать от дефолтного свой middleware, с валидацией и эксепшенами :)
Бизнес-логика, само собой, отправляется в контроллеры соответствующих сущностей, т.е. понятно, что никто не пишет весь REST инлайн-функциями, последняя строчка вживую выглядит скорее как:
Маппинг входящего json в объекты берёт на себя Eloquent, он же обрабатывает ошибки. Скажем PUT (и, кажется, даже PATCH) можно отработать так:
Я это всё к тому, что PHP (в том числе к моему собственному удивлению) на сегодня эволюционировал в довольно пристойную экосистему, и не надо вот так через губу о нём свысока отзываться :) В активе у него — большая база разработчиков (я думаю, самая большая на сегодня, JS ещё пару лет догонять), удобный в освоении синтаксис "для ленивых" (чего стоит, например, разрешённая запятая после последнего элемента массива), множество вшитых быстрых функций для работы с актуальными для веба данными (всякие array_merge, array_column), отличный менеджер пакетов Composer и репозиторий Packagist для него, в отличие от Node не хранящий в себе всякий однострочный шлак (см. анекдот про left-pad).
Ну и над всем этим — open-source фреймворки (Laravel, Symfony) и CMS (Drupal и WordPress) с колоссальной накопленной базой кода и готовых решений. Так что если надо сегодня делать что-то, чему надо быстро взлететь, лихорадочно расти и начать приносить доход — я пожелаю удачи любителям Go, Erlang, F# и что там ещё придумали в последние годы, а сам буду набирать команду на PHP.
Ещё меньше?
NB: это я ещё из тех месье, что знают толк в извращениях — натянул Eloquent на Slim вместо Lumen, для которого Eloquent — родная ORM.
Ещё меньше?
NB: это ещё я знаю толк в извращениях, скрестил когда-то ежа с ужом, Slim и Eloquent, и с тех пор ленюсь посмотреть на Lumen, для которого Eloquent родная ORM.
Ссылку на список литературы на оцифровку я привёл, вы там нашли что-нибудь, что есть уже на Флибусте/Рутрекере?
Хорошо, если что-то найдётся в уже более-менее готовом виде, и надо будет только отформатировать. Но скорее всего большинство книг придется сканировать с нуля, и цена в 8700 не кажется завышенной. Посчитайте хотя бы по зарплатам: допустим, что оператор-надомник стоит 40000 рублей (это предельно мало для Москвы) и цифрует 20 книг в месяц (выше по комментам есть несколько оценок в этом ключе), 60 книг за 3 месяца. Пусть цифровать надо 9000 (а 2000 найдутся готовые), значит операторов надо 150 человек и их ФОТ составит 18 миллионов. Налогов и взносов в фонды с этих денег надо будет заплатить ещё примерно 8 миллионов. Далее, редакторы-корректоры — пусть вдвое дешевле, а то развелось этих гуманитариев: ещё 13 миллионов ФОТ + НДФЛ + фонды. Верстальщики, которые в итоге готовые книжки соберут — всяко ещё миллионов 10. Юристы, бухгалтеры, менеджеры — ещё 10. Минус 18% НДС, остается 19 миллионов, или 20%, вполне умеренная маржа для нынешней России, где 20% в рубле за 3 месяца можно получить, просто купив швейцарские франки и положив их под матрас.