• Доступен PhpStorm 2017.3
    0
    Переключение веток переключает tasks? Будет ли оно работать, если ветку сменю в консоли и потом вернусь в редактор, сменит ли он контекст?
    p.s. Извини, нет возможности сейчас самому проверить.

  • PHP жив. PHP 7 на практике
    0
    Ну вот же. Я об этом же, если требование по знаниям такие же как в шарпах и джавах, то зачем писать на костылях и год ждать новую версию, чтобы в возращаемых типах указывать вариант с нулл.

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

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

    Сам php становится лучше, более функцинальным, качественным и т.д. Но и вход в него растёт.
  • PHP жив. PHP 7 на практике
    +1
    Знаете какой самый популярный вопрос по тегу laravel в местном тостере? Про неймспейсы, люди не понимают почему у них не работает как в примерах Foo::bar();

    В посте я написал о том, что PHP оброс новыми фичами и так называемые специалисты в них до сих пор не разбираются. Порог входа значительно вырос. Найти специалиста, который знает ООП и может спокойно писать на фреймворке уровня symfony невероятно сложно и дорого, потому и теряется конкурентное преимущество.
  • PHP жив. PHP 7 на практике
    –1
    Ну раз у вас так хорошо с проектами, может со мной поделитесь? Я с легкостью найду исполнителей за хорошие деньги, которые с радостью согласятся бросить адский легаси.
  • PHP жив. PHP 7 на практике
    –3
    Я php-шник, потому хорошо знаю о чём говорю. Среди моих знакомых хороших программистов практически не осталось чистых php-шников, теперь для хорошей зарплаты надо нырять во фронтэнд. Дело не только в джавасрипте, есть ещё джава и шарп.
    Да и в целом веб рынок сжался с приходом фейсбуков, уже не нужно столько типовых стэнд элон сайтиков и магазинов.
  • PHP жив. PHP 7 на практике
    0
    Да сcc..., странные результаты.
    Вот сравнение за 5 лет php, nodejs и javascript trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F060kv,%2Fm%2F0bbxf89,%2Fm%2F02p97
    Популярность php уходит и его вытесняют другие языки.
    Но даже это не важно, беспокоят именно хорошие проекты с хорошей оплатой, их стало значительно меньше.
  • PHP жив. PHP 7 на практике
    –1
    Понятное дело, что умирать он будет долго, вон даже Fortran, COBOL до сих пор используются в проде. Но с новыми проектами с нормальными бюджетами уже туго, это сильно бросается в глаза.
    Даже простая проверка трендов это демонстрирует. trends.google.com/trends/explore?date=all&q=%2Fm%2F060kv
  • PHP жив. PHP 7 на практике
    +2
    Я говорю о проектах с нормальным бюджетом, где php-шники получают как минимум не меньше коллег c других языков. Такие проекты исчезают. За последних пару лет их количество сократилось в разы, отделы php начали сокращать и переучивать на javascript ± node.
    p.s. У меня информация о Минских компаниях, который в основном работают на запад. «Диджитал» и Битрикс конторы с дешёвой и некачественной рабочей силой я не считаю.
  • PHP жив. PHP 7 на практике
    –18
    PHP всё же умирает.
    С новыми фичами мы лишились конкурентного преимущества — быстро и дешево. С фреймворками вроде Zend и Symfony и заморочками с типизацией время и объёмы кода стали сравнимы с Java и C#, в которых данные фичи существуют давно и реализованы не так костыльно как в PHP. И пока мы изобретаем гибернейт и играем во взрослый язык, конкуренты наоборот становятся проще и более дружественными к вебу.

    А на рынке «быстро и дешево» позиции заняли nodejs и go, на подходе kotlin. Спасает ещё популярность laravel, но уровень разработчиков там печален.
  • Кораблестроение 17 века и ваши неудачные проекты по разработке: найдите пять отличий
    –18
    Практически в любом проекте можно найти кучу проблем, спешки и костылей, но они не потонули, а некоторые даже приуспели. Легко постфактум указывать на ошибки.

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

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

  • Что же такое этот GraphQL?
    0
    Я согласен, что стандарт — хорошо. Ещё одно стандартное апи помимо ресурсооринтированного это здорово, лучше, чем изобретать самому декораторы. Но это не делает его не REST-ом, например можно использовать прокси-кэш.
  • Что же такое этот GraphQL?
    0
    Да, для REST есть ограничения, чтобы считаться RESTful, но среди них нет ничего про заголовки, урлы и т.д., что является лишь одной из реализаций, но не обязательным условием. Да и заголовков, урлы — это протокол передачи данных, это HTTP нужны метод, ури, заголовки… Вместо http может быть другой протокол, это одно из требований слоёностии REST.
  • Сравнение REST и GraphQL
    +3
    Уже не раз сталкивался с этой проблемой, разработчики не знают что такое REST и из-за этого делают уродливые апи с кучей лишних вызовов.
    REST — это архитектура предпологающая клиент-серверное взаимодействие, БЕЗ хранения промежуточного состояния. Нет состояния, нет проблем, есть куча фишек вроде кеширования и слоистости. Это не про ресурсы /user:id user/:id/comment/:id, не про вербальность GET-PUT-DELETE… как думают многие и откуда растёт миф:
    Пользоваться старой REST-моделью это как заказывать пиццу, затем заказывать доставку продуктов, а затем звонить в химчистку, чтобы забрать одежду. Три магазина – три телефонных звонка.

    REST не запрещает тебе сделать метод POST /doMagic {pizza: {}, address: {}, tea: {}}, и если ты пошлёшь все необходимые данные, то он закажет пиццу, доставку и включит чайник. Отличие от классического подхода то, что ты не установил адрес доставки при регистрации пользователя, а при запросе взял его сс сервера, а отправляешь его явно на /doMagic в виде сырых данных либо идентификатора по которых его можно получить из стораджа (вреде userId).

    Это к тому, что GraphQL тоже является REST подходом, просто у него апи не VERB resource/:id и вам никто не мешает делать такое апи. Например мы, посылаем декораторы, чтобы сказать какие поля получить
    GET /user/:id?decorators=name,address,comments.count.
    Не придумывайте себе исскуственных ограничений, которые не описаны в настоящем REST.
  • Что же такое этот GraphQL?
    0
    Уже не раз сталкивался с этой проблемой, разработчики не знают что такое REST и из-за этого делают уродливые апи с кучей лишних вызовов.
    REST — это архитектура предпологающая клиент-серверное взаимодействие, БЕЗ хранения промежуточного состояния. Нет состояния, нет проблем, есть куча фишек вроде кеширования и слоистости. Это не про ресурсы /user:id user/:id/comment/:id, не про вербальность GET-PUT-DELETE… как думают многие и откуда растёт миф:
    Пользоваться старой REST-моделью это как заказывать пиццу, затем заказывать доставку продуктов, а затем звонить в химчистку, чтобы забрать одежду. Три магазина – три телефонных звонка.

    REST не запрещает тебе сделать метод POST /doMagic {pizza: {}, address: {}, tea: {}}, и если ты пошлёшь все необходимые данные, то он закажет пиццу, доставку и включит чайник. Отличие от классического подхода то, что ты не установил адрес доставки при регистрации пользователя, а при запросе взял его сс сервера, а отправляешь его явно на /doMagic в виде сырых данных либо идентификатора по которых его можно получить из стораджа (вреде userId).

    Это к тому, что GraphQL тоже является REST подходом, просто у него апи не VERB resource/:id и вам никто не мешает делать такое апи. Например мы, посылаем декораторы, чтобы сказать какие поля получить
    GET /user/:id?decorators=name,address,comments.count. Не придумывайте себе исскуственных ограничений, которые не описаны в настоящем REST.

  • Laravel — экосистема, а не просто PHP-фреймворк
    0
    Да не проходило ничего мимо. Ещё во времена php4 все провали ddd и прочие технологии с java-asp, потому что литература по архитектуре была исключительно для этих языков. С тех пор появились более удобные инструменты как в самом языке, так и в сторонних библиотеках. Сейчас очередная волна, которая загнала язык в могилу, так как мы утратили преимущества — быстро, дешево, легкое в поддержке и маштабировании. Мы пришли на территории java-.net, с куда более ущербным языков в плане ООП.
    Мы спорили о том, что DDD убьёт PHP ещё во время бет symfony 2, с тех пор практически все перешли к javascript или devops. При этом в большом мире начали уходить от энтерпрайзщины и спрингов, появился котлин.
  • Laravel — экосистема, а не просто PHP-фреймворк
    0
    В этом и весь ад DDD, у каждого своё понимание, кто чего понахватался из большой синей книги, а то и вовсе из статей в интернете. Я пока не видел ни одного нормального проекта с DDD, который было бы легко поддерживать и расширять, потому отношу его к антипаттернам. И отсутствие интруменов для DDD ставлю в плюс Laravel.
  • Laravel — экосистема, а не просто PHP-фреймворк
    –1
    Доработка сетапа нужна везде, но именно в laravel и yii она требуется меньше, так как фреймворк из коробки содержит кучу приятныхз фишек, о чём собственно и статья. Когда ты садишься работать за симфони после ларочки, то чувствует себя вообще голым, разве что визитки с таким сетапом разрабатывать, нет очередей, редиса и т.д.

    Про DDD и гексогоналку. Мне казалось, что суть этих технологий как раз в отсутствии привязки к стораджам и всяким eloquent или doctrine. Мне кажется вторая даже вреднее, так как люди тешат себя иллюзией о правильной архитектуре, а по сути вместо спагетти кода пишут лазанью.

    Про документацию вы правы, там примеры демонстрируют ТОЛЬКО конкретный инструмент и не связаны друг с другом. Но так везде, в доке по php даже есть приписка про этот момент. Но есть laracast демонстрирующий хорошие практики. В доке был ещё пример полноценного приложения, но его найти не могу.

    Ну а в остальном ваши придирки субьективны и зависят от разработчика. У меня за спиной десяток проектов с laravel и пяток с symfony, в ларавеле ниже порог входа и куча говнокода от авторов не осилевших доку до конца, в симфони же беспощадная слоёная архитектура от авторов не осилевших php и в поддержке они на порядок сложнее, даже хуже битрикса.
  • Вводим рейтинг участника «Хабра» и «Тостера» на «Моём круге»
    0
    Не стоит баги и охлократию выставлять как контролируемое саморегулирующееся сообщество.
  • Вводим рейтинг участника «Хабра» и «Тостера» на «Моём круге»
    0
    Если не заморачиваться и отвечать время от времени, то это прекрасный результат. Как любят писать эйчары — этого достаточно, чтобы войти в 5% лучших пользователей ресурса, да и количество ответов на первый взгляд заставляет думать, что чел в чём-то шарит.
    Я не против того, чтобы ответить самому можно было, но эти ответы не должны учитываться в рейтинге пользователей. Тем более ответы у него не верные и будут только путать других пользователей ресурса, которые не проверят кто задавал и кто отвечал на вопрос.
  • Вводим рейтинг участника «Хабра» и «Тостера» на «Моём круге»
    0
    Лучше бы тостер починили, а то там рейтинг легко обузится, т.к. авторы вопросов могут сами же себе отвечать и выбирать ответ как верный. Вот яркий пример о я чём писал в саппорт пол года назад https://toster.ru/user/BonBonSlick/answers

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

    Очень необъективные рейтинги, чтобы включать их в резюме.
  • Компетентность не имеет пола: о гендерном балансе и тренде развития женского кодинга
    +13
    [сарказм]Мужики тоже думают одним местом, может потому зачастую код у нас получается х**вый?[/сарказм]

    Не раз работал и работаю с женщинами-программистами, не замечал никакой зависимости между полом и кодом.
  • Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    0
    Я в начальном комментарии указал пару проблем, но вся статья хреновая, а главное вредная.
    Именно потому, я не хочу делиться опытом, потому что мои советы тоже могут быть вредными за пределами контекста. Надо опираться на серьёзную литературу, где рассмотрена куча разных кейсов, она не раз уже упоминалась.
    К тому же в php есть готовые решения вроде doctrine-propel, которые значительно лучше поделки автора, который даже php знает с оговорками.
  • Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    +1
    Да почитайте вы их, там есть реализации с кодом, плюс в посте выше я писал о Нильссоне, у него практики ещё больше. Но вы даже с терминами не разобрались, а пытаетесь делиться «опытом».

    Карнеги хорош, кода хочешь навешать лапши на уши. Здесь же профессиональный ресурс, где люди обмениваются знаниями и опытом, а не заводят новых друзей. В отношении вас я умышленно применил агрессию и троллинг, дабы заставить вас усомниться и освежить знания.
  • Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    0
    Зачем писать? Есть книги Эвайнса и Фаулера и куча статей от этих же авторов — это райт вэй. Надо их внимательной читать, а не набравшись по вершка и статьям лепить свои велосипеды.
  • Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    0
    Почему удалась? Статья ужасная и вредная для прочтения. Не дай о кто-то прочтёт, не дойдёт до комментариев и будет это воспринимать как райт вэй. Автору надо подучить сам php, а затем перечитать книги на который он ссылался и почитать какого-нибудь Нильссона, чтобы увидеть практическую реализацию.
  • Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    +1
    У вас всё плохо, очень плохо.
    DDD вы не понимаете.
    Enity — хрень с защищёнными свойствами в массиве, магическим __call и даже сеттер для айди работает с неявным поведением $this->id = $this->id == 0? $id: $this->id;
    Репозиторий который не репозиторий, в котором мэппер, который почему-то не мэпит, а персистит данные.
    Контекст непонятная штука, чей контракт зафиксирован в виде абстрактноо класса и не предполагает нормальную инъекцию зависимостей.

    Ну и это первая половина проблемы. Вы не знаете синтаксиса php и работаете с отключёнными ошибками вроде E_NOTICE, E_DEPRECATED, потому принимаете объекты по ссылке. Даже оформление кода не по PSR и вооще пахнет временами php 4.

    И ещё куча ног торчит из стога.
  • Stack Overflow вывел из Vim уже больше миллиона пользователей
    +3
    Ссылка на этот вопрос ходит как мем и имеет мало общего с количеством людей реально застрявших в виме.
  • Vue.js для сомневающихся. Все, что нужно знать
    0
    Интересует будущее Vue, где можно почитать о планах? За последние годы я переел этих тайпскриптов, флоу, вебпаков и *-cli. Сейчас в отпуске свой пет проект начал писать на первом angular, без всяких обвесок и вдруг вспомнил, что люблю программирование.
    Vue выглядит как неплохая альтернатива angular1, да и схожесть упрощает освоение, но она же пугает, как бы авторы не пошли по тому же пути c предпроцессорами, типизацией и функциональщиной.
  • Be Agile. Как уйти от Waterfall
    0
    Ну да, того самого мифического страшного водопада, где всё спланировано и разбито на участки на годы вперёд не было. Он как бандеровцы, придуманный враг, чтобы продавать аджайл.
  • Правильная коммуникация на примере волейбола
    +1
    В китайских денди для валейбола с изображения был баг с очередностью опроса джойстиков: опрашивался первый, если была нажата кнопка, то выполнялось действие для первого игрока, а затем опрашивался не второй, а снова первый. Сидя на первом джойстике можно было заспамить кнопку и у второго игрока не было шансов.
    В реальной жизни та же проблема, спамеры побеждают, потому что не передают ход по очереди, а стреляют цепочками зачастую противоречивых требований.
  • Новый быстрый старт с PHPixie: строим цитатник коммит за коммитом
    +1
    >> $components = $this->components();
    Ну почему не заюзать нормальный DI с явной инъекцией нужных объектов, а не таскать каштаны голой рукой из огня.
  • Краткий обзор нововведений в Laravel 5.4
    +1
    Нет, потому недокументированными методами и не нужно пользоваться, они могут быть удалены без предупреждения. Я даже пример привёл.
  • Краткий обзор нововведений в Laravel 5.4
    +2
    Важно ни его наличие в коде, а наличие в документации. Вот пример из неё
    The share method has been removed from the container. This was a legacy method that has not been documented in several years. https://laravel.com/docs/5.4/upgrade#upgrade-5.4.0

  • Краткий обзор нововведений в Laravel 5.4
    +1
    Пока этого нет в документации, использовать не советуется, т.к. Тейлор любит убирать незадокументированные фичи, в текучем релизе есть такие поломки BC.
  • Краткий обзор нововведений в Laravel 5.4
    +4
    Видимо вы об этом
  • Как Ionic 2 помогает мне вникнуть в angular 2
    0
    Сейчас и для angular 2 есть NativeScript http://docs.nativescript.org/angular/start/introduction.html
  • Блеск и нищета php. Эволюция языка от 4.x к 7.1
    +1
    Основные изменения произошли в инфраструктуре и головах разработчиков, которые начали этой инфраструктурой пользоваться. Ускорили производительность, улучшили синтаксис, много изменений внутри, но ничего принципиально нового, что бы вывело язык на новый уровень не случилось. А вот то, что начали пользоваться компосером и фреймворками сильно всё поменяло, хотя ещё и во времена php4 были pear, pecl, seagull, cakephp и т.д.

    Очень хотелось бы чтобы улучшилась асинхронность, многопоточность, появился loop, библиотеки стали неблокирующими, но глядя на костыли с какими добавляются новые фичи, думаю продолжу при надобности подтыкать проект на других языках nodejs, go. Может и не надо делать универсальный инструмент.

  • Как работают ИТ-специалисты. Даниил Пивоваров, Vscale
    +6
    Неужели так важно знать каким to do менеджером и какой читалкой пользуется человек, если он сам работает по 10-15 часов, ещё и других уговаривает?
    Почему бы не учиться эффективной работе у тех, справляется своими делали в рабочее время и никого не должен уговаривать поработать.
  • Идея для Хабра: уровни сложности статей
    +2
    Уровень сложности может определить только сам читающий. Не вижу проблемы, чтобы новички читали сложные тексты, пусть они и поймут только 30%, но зато будут знать куда расти.
    Другая беда, что сейчас развелось специалистов, насмотревшихся простых видеокурсов, но так и не дошедших до серьёзной литературы и не подозревающих о ней.
  • Почему я бы не стал использовать Rails для нового проекта
    –2
    Ну что за гадкая привычка молча лепить минус и портить карму, отпишитесь хоть почему. Я же привёл аргументированную точку зрения, если надо ещё докину аргументов и ссылок.