спасибо за историческую справку. Мне всегда нравились такие места, хоть я и никогда не бывал там и не работал. Мне кажется когда все вокруг такое современное, в стекле, айтишное до мозга костей, да еще и субтропический климат - это создает такую атмосферу, что хочется создавать уникальные и классные вещи, чем когда ты сидишь где-нибудь в Купчино в 4х стенах))
поставил плюс статье и карме, потому что очень нравится идея, мне нравится PHP и я поддерживаю любые начинания каждого в этом направлении, но, соглашусь, мало конкретики, давайте примеры хотя бы с гитхаба или тут ссылочки скиньте, плес)
если вы уже пробовали поднимать веб-сокет скиньте, если не сложно, пет-проект ну или то что получилось и реально работает, какие реальные минусы и сложности были у вас, с чем смогли справиться, с чем нет. Лично мне интересен ваш путь, ваш опыт и как вы справлялись с трудностями, я бы посмотрел с удовольствием как это работает, развернул бы, глянул как устроена ваша архитектура и тд (ну если это не суперсекретное и вам не жалко)
Ну для начала, конечно же, благодарность автору за проделанную работу, какую, пока не акцентируем внимание, все же было потрачено время и на коддинг, и на документацию и на пост, поэтому, автор - вы молодец, хотя бы потому, что не сидите на диване и что-то творите.
Теперь по существу, я не против чего-то нашего "отечественного", но и игнорировать существующие, проверенные временем современные практики в программировании, тоже нельзя. Нет смысла изобретать по новой велосипеды в виде классов Session, Request, и тд. и тп., ну т.е. если вы туда копипастите реализации Symfony и других фрейморков, то куда ни шло, хотя задал бы очевидный вопрос, зачем? если можно через composer получить готовый, автообновляемый код... А если вы пишите что-то свое, да еще и в одиночку, остается лишь надеяться, что через много лет оно станет идеальным для текущего времени, но совершенно устаревшим для того времени, к которому код будет дописан до конца.
Я все же надеюсь, что вы найдете помощников, одному кодить неправильно, нужен код-ревью, взгляд со стороны, архитектурные решения в одиночку не должны приниматься, и еще я бы еще обратил внимание на использование линтеров, точнее их "неиспользование", отсутствие тестов - если вы в начальном этапе - лучше сразу пишите тесты, когда кода станет тонна, покрывать тестами замучаетесь. Вы должны понимать что любое "незначительное" изменение может сломать уже существующий функционал, поэтому о важности тестов говорить я думаю не стоит.
Поэтому, если у вас есть план, роадмэп, время и силы и огномное желание довести до конца начатое, то я желаю вам удачи в вашем нелегком деле.
не будьте столь категоричны, ну да 0x131315 высказался, возможно слишком высокими терминами, но в целом он прав ведь.
люди потеряли как минимум веру и желание вообще что-либо где-то публично хранить; заблокированный пользователь, а в случае резонанса, тысячи других ведомых, также утратят всякое желание кодить в опен-сорс, что деструктивно скажется на ИТ-индустрии в целом, и если это пойдет по сарафанному радио , то доверие к подобным ресурсам упадет до минимума.
Никому не хочется делать вклад туда, что по мановению руки какого-то политика, будет удалено и заблокировано, у кого-то это возможно труд всей его жизни (у многих аккаунты по 10-15 лет).
так что я согласен с тем, что это не приемлемо, коли уж от тебя зависят миллионы людей в мире, нужно также отвественность нести, потому что мне это все напоминает корпорацию, уровня Google/Microsoft, где трудятся сотни тысяч человека, а потом владелец контрольного пакета говорит: "А мне надоело, продам компанию по частям, всех людей уволю". Гробить жизни тысяч работяг, карму точно не улучшит, это не гуманно.
Зачем так странно доставать билдер когда есть фасад Schema?
Что такое DataModel? Если это ваша реальная модель (Eloquent), то вполне логичный вопрос: зачем вы модели используете в миграциях. Модель вещь переменная, сначала вы добавили таблицу, а через три месяца удалили. В миграциях кож последовательный, таблица должна быть добавлена и потом быть удалена. И на момент когда вы с нуля катите миграции DataModel уже не будет. Или вы предлагаете рефачить 100500 миграция каждый раз когда удаляете таблицу и Model из проекта?
Я вообще если честно не понимаю зачем вообще разрешать невалидные даты, какая была задумка у разработчиков MySQL когда они это придумывали? У меня нет идей как это можно использовать в продакшн..
Я понимаю вводить опции ускоряющие чтото за счет чего то другого, или опция которая увеличивает максимальную длину строки для group concat, тут ты сам решаешь что тебе важно или нет, в зависимости от ситуации, но опция разрешающая невалидные значения это высший пилотаж)))
ну либо не просто включить, а писать нормальный код, например, в одном из старых проектов видел примерно такое:
```php
$from = date('Y-m-01 00:00:00');
$to = date('Y-m-31 23:59:59');
```
и SQL-запрос в который передавались эти даты:
```SQL
select *
from activities
where timestamp between :from and :to
```
так вот такого г… в проекте было полно и что самое интересно этот код работал идеально, пока я не попытался переложить это на Postgres, там все валилось в тартарары, причем валилось не всегда, рандомно, периодически…
а дело было в том, что когда в месяце был 31 день — все было идеально, а когда в месяце было 28/29/30 дней были Exception-ы на уровне БД, т.к. Postgres валидировал дату и писал, что нет даты 2018-02-31 23:59:59, что она находится за пределами допустимых значений.
Поэтому зная это и другие нюансы БД подобных Postgres-у, ты уже не будешь писать такое, а будешь писать примерно такое:
с одной стороны, если ты всю жизнь планируешь сидеть на MySQL / MariaDB, то возможно не стоит об этом запариваться об этой строгой типизации, лишняя морока и гемор. Особенно, если ты новичок.
Ну mysql очень расслабляет, если на нем долго сидишь… вообще стандартный SQL со строгой типизацией знать полезно а то миграция проекта с mysql на postgres может вылиться в очень большую головную боль в рефакторинге 100500 запросов процедур и триггеров
Да, трюки, хаки это все для выпендрежа, возможно для собесов, где проверяют не ваши умения, а на насколько глубоко вы копнули в мануалы, те тестируют глубину ваших знаний. А в работе подобное точно использовать нельзя, так как команда может состоять из специалистов разного уровня и код должен быть простой понятный для всех, а не только для гиков
В АПИ не один метод, куча опций, доп справочников + обработка ошибок и других нестандартных ситуаций, мне вот например, удобнее подключить через composer некий клиент, который уже умеет общаться с АПИ и прописать в конфиге access_key.
Я не хочу вникать в тонкости и нюансы, думать об эндпойнах, хидерах, формировать реквесты, обрабатывать респонсы, использовать в проекте всякие curl с передачей туда непонятно чего, плюс обмазывать свой проект доп классами и обработчиками, я например, знаю этот сервис и этого достаточно.
Далее просто чтобы сервис работал:
— подключить сервис через DI
— чтобы был публичный интерфейс в соответствии с АПИ, чтобы не приходилось доку читать
— чтобы все методы возвращали DTO, чтобы было понятно что там, потому что с json приведенному к массиву работать не удобно, нужно проверять наличие ключей, опять же знать какие там ключи и тд.
А если я захочу поменять что-то, я просто поменяю библиотеку, точно также.
Это как минимум удобно.
Также, используя какой-то сторонний компонент, я хочу надеяться, что он работает как надо, для этого код должен быть покрыт тестами на 100%.
спасибо за историческую справку. Мне всегда нравились такие места, хоть я и никогда не бывал там и не работал. Мне кажется когда все вокруг такое современное, в стекле, айтишное до мозга костей, да еще и субтропический климат - это создает такую атмосферу, что хочется создавать уникальные и классные вещи, чем когда ты сидишь где-нибудь в Купчино в 4х стенах))
Это получается что-то вроде Силиконовой долины или Сколково, но только в Испании?
поставил плюс статье и карме, потому что очень нравится идея, мне нравится PHP и я поддерживаю любые начинания каждого в этом направлении, но, соглашусь, мало конкретики, давайте примеры хотя бы с гитхаба или тут ссылочки скиньте, плес)
если вы уже пробовали поднимать веб-сокет скиньте, если не сложно, пет-проект ну или то что получилось и реально работает, какие реальные минусы и сложности были у вас, с чем смогли справиться, с чем нет. Лично мне интересен ваш путь, ваш опыт и как вы справлялись с трудностями, я бы посмотрел с удовольствием как это работает, развернул бы, глянул как устроена ваша архитектура и тд (ну если это не суперсекретное и вам не жалко)
Тоже выскажусь, пожалуй,
Ну для начала, конечно же, благодарность автору за проделанную работу, какую, пока не акцентируем внимание, все же было потрачено время и на коддинг, и на документацию и на пост, поэтому, автор - вы молодец, хотя бы потому, что не сидите на диване и что-то творите.
Теперь по существу,
я не против чего-то нашего "отечественного", но и игнорировать существующие, проверенные временем современные практики в программировании, тоже нельзя. Нет смысла изобретать по новой велосипеды в виде классов Session, Request, и тд. и тп., ну т.е. если вы туда копипастите реализации Symfony и других фрейморков, то куда ни шло, хотя задал бы очевидный вопрос, зачем? если можно через composer получить готовый, автообновляемый код... А если вы пишите что-то свое, да еще и в одиночку, остается лишь надеяться, что через много лет оно станет идеальным для текущего времени, но совершенно устаревшим для того времени, к которому код будет дописан до конца.
Я все же надеюсь, что вы найдете помощников, одному кодить неправильно, нужен код-ревью, взгляд со стороны, архитектурные решения в одиночку не должны приниматься, и еще я бы еще обратил внимание на использование линтеров, точнее их "неиспользование", отсутствие тестов - если вы в начальном этапе - лучше сразу пишите тесты, когда кода станет тонна, покрывать тестами замучаетесь. Вы должны понимать что любое "незначительное" изменение может сломать уже существующий функционал, поэтому о важности тестов говорить я думаю не стоит.
Поэтому, если у вас есть план, роадмэп, время и силы и огномное желание довести до конца начатое, то я желаю вам удачи в вашем нелегком деле.
не будьте столь категоричны, ну да 0x131315 высказался, возможно слишком высокими терминами, но в целом он прав ведь.
люди потеряли как минимум веру и желание вообще что-либо где-то публично хранить; заблокированный пользователь, а в случае резонанса, тысячи других ведомых, также утратят всякое желание кодить в опен-сорс, что деструктивно скажется на ИТ-индустрии в целом, и если это пойдет по сарафанному радио , то доверие к подобным ресурсам упадет до минимума.
Никому не хочется делать вклад туда, что по мановению руки какого-то политика, будет удалено и заблокировано, у кого-то это возможно труд всей его жизни (у многих аккаунты по 10-15 лет).
так что я согласен с тем, что это не приемлемо, коли уж от тебя зависят миллионы людей в мире, нужно также отвественность нести, потому что мне это все напоминает корпорацию, уровня Google/Microsoft, где трудятся сотни тысяч человека, а потом владелец контрольного пакета говорит: "А мне надоело, продам компанию по частям, всех людей уволю". Гробить жизни тысяч работяг, карму точно не улучшит, это не гуманно.
Прочитал на одном дыхании. спасибо!
Там еще с картинками из Симсонов))
Добрый день,
У меня два вопроса:
Интересно, т.е. по вашему Yii и Laravel достойны 1 и 2 места?
Мне всегда казалось, что рейтинг должен начинаться с Symfony и выглядеть примерно так:
Symfony
Laravel
Yii 2
Zend
и тд
Мне доводилось программировать на каждом из них, причем во всех мажорных версиях начиная с первых. В каждом из них я смотрел под капот в исходники.
ИМХО, я бы не ставил Symfony так далеко.
Я вообще если честно не понимаю зачем вообще разрешать невалидные даты, какая была задумка у разработчиков MySQL когда они это придумывали? У меня нет идей как это можно использовать в продакшн..
Я понимаю вводить опции ускоряющие чтото за счет чего то другого, или опция которая увеличивает максимальную длину строки для group concat, тут ты сам решаешь что тебе важно или нет, в зависимости от ситуации, но опция разрешающая невалидные значения это высший пилотаж)))
```php
$from = date('Y-m-01 00:00:00');
$to = date('Y-m-31 23:59:59');
```
и SQL-запрос в который передавались эти даты:
```SQL
select *
from activities
where timestamp between :from and :to
```
так вот такого г… в проекте было полно и что самое интересно этот код работал идеально, пока я не попытался переложить это на Postgres, там все валилось в тартарары, причем валилось не всегда, рандомно, периодически…
а дело было в том, что когда в месяце был 31 день — все было идеально, а когда в месяце было 28/29/30 дней были Exception-ы на уровне БД, т.к. Postgres валидировал дату и писал, что нет даты 2018-02-31 23:59:59, что она находится за пределами допустимых значений.
Поэтому зная это и другие нюансы БД подобных Postgres-у, ты уже не будешь писать такое, а будешь писать примерно такое:
```php
$from = date('Y-m-01 00:00:00');
$to = date('Y-m-t 23:59:59');
```
с одной стороны, если ты всю жизнь планируешь сидеть на MySQL / MariaDB, то возможно не стоит об этом запариваться об этой строгой типизации, лишняя морока и гемор. Особенно, если ты новичок.
Ну mysql очень расслабляет, если на нем долго сидишь… вообще стандартный SQL со строгой типизацией знать полезно а то миграция проекта с mysql на postgres может вылиться в очень большую головную боль в рефакторинге 100500 запросов процедур и триггеров
Он вроде и олап кубы поддерживает через экстеншены… это почти уже как oracle, хотя с последним даже не работал никогда, но про кубы в нем слыхивал
Не в первый раз вижу комменты с текстом «del». Что это означает на сленге хабра?
Да, трюки, хаки это все для выпендрежа, возможно для собесов, где проверяют не ваши умения, а на насколько глубоко вы копнули в мануалы, те тестируют глубину ваших знаний. А в работе подобное точно использовать нельзя, так как команда может состоять из специалистов разного уровня и код должен быть простой понятный для всех, а не только для гиков
Минусуют видимо те, у кого есть более элегантное решение
В АПИ не один метод, куча опций, доп справочников + обработка ошибок и других нестандартных ситуаций, мне вот например, удобнее подключить через composer некий клиент, который уже умеет общаться с АПИ и прописать в конфиге access_key.
Я не хочу вникать в тонкости и нюансы, думать об эндпойнах, хидерах, формировать реквесты, обрабатывать респонсы, использовать в проекте всякие curl с передачей туда непонятно чего, плюс обмазывать свой проект доп классами и обработчиками, я например, знаю этот сервис и этого достаточно.
Далее просто чтобы сервис работал:
— подключить сервис через DI
— чтобы был публичный интерфейс в соответствии с АПИ, чтобы не приходилось доку читать
— чтобы все методы возвращали DTO, чтобы было понятно что там, потому что с json приведенному к массиву работать не удобно, нужно проверять наличие ключей, опять же знать какие там ключи и тд.
А если я захочу поменять что-то, я просто поменяю библиотеку, точно также.
Это как минимум удобно.
Также, используя какой-то сторонний компонент, я хочу надеяться, что он работает как надо, для этого код должен быть покрыт тестами на 100%.
В общем, ИМХО, он все-таки нужен.