Сергей Протько

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

По сути, websockets будут продуктивнее работать (если мы не берем в расчет HTTP2), но вам придется реализовывать мультиплексирование запросов/ответов, как-то писать свой протокол поверх и словом куча гемороя. При том что профита по производительности в сравнении со старым добрым HTTP + Keep Alive не так много.

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

p.s. пробовал делать все на websockets но без мультиплексирования, у меня небыло необходимости разруливать конкурентные запросы или паралельные, все шло через очередь да и задачи были очень простые. А почему был выбран websockets - потому что всеравно использовался а для одного метода еще API писать было лень.

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

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

Вообще подобные задачи, если вам в принципе плевать на внутреннее состояние ваших энтити, то есть вы прекрасно знаете что вы меняете и зачем - лучше использовать DBAL или DQL напрямую в репозитории.

Что быстрее, сканирование одного индекса или манипуляции с четырьмя индексами с целью получить пересечение/объеденение (в зависимости от логики запроса) результатов сканирования?

Функционал вьюшки и временных таблиц отсутствует у части баз данных. Посему доктрина из коробки не умеет работать с оными.

docs.doctrine-project.org/en/latest/reference/nati...

Как-то так... Желательно это дело инкапсулировать внутри репозитория.

Аналогов нет. А $eval несколько другая штука.

Да на самом деле ватман + стикеры и Kanban-борду для джиры, спецификации и требования (а так же тест кейсы, definition of done) к самим стори в джире + гуглодоки (для QA).

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

По поводу серверного API - как это не странно, тупо документация в markdown написанная руками которая хранится в git. Это с одной стороны геморой, так как надо руками поддерживать, с другой стороны удобно, так как это просто (что может быть проще?) + можно посмотреть изменения в API за период, что бывает удобно.

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

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

Доктор, что со мной?

Волчанка

или неправильно рассматриваю обучение в целом

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

если вы не знаете ничего из списка, то без разницы в общем-то. Если планируется сложный UI и вы не знаете Angular то лучше взять React с его виртуальным DOM, тогда шансы что вы запорите производительность приложения дип ватчем нивелируется.

Что до Angular2 - он еще не скоро будет стабильным, да и если будете соблюдать рекоммендации из angular styleguide и будете использовать es2015 (babel.js), то проблем с миграцией будет не так много, если оно вам вообще нужно будет.

У Meteor вообще чуть другая концепция. Там основная фишка - один код на клиенте и на сервере. Но это накладывает свои ограничения.

Polymer - няшка. но это только UI. Сверху вам всеравно придется что-то еще использовать.

благодаря различным плагинам можно любую CMS приспособить для своих нужд.

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

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

Ссылку на репозиторий вам уже привели.

Вообще стоит почитать оригинальную книгу. Хотя и на википедии информации предостаточно в сжатом виде.

Если без лишней воды, можно еще послушать лекции Сергея Немчинского (там помимо GoF рассказывается в принципе про основы ООП, GRASP и т.д. Что вобщем-то логично ибо без основ понять почему так а не иначе сложно и все сведется к простому заучиванию. и еще несколько лекций по рефакторингу).

Ну и еще рекомендую почитать/посмотреть дяду Боба и подчерпнуть там чего о SOLID.

Если нет, то на Java?

Java это нэйтив платформа для андроида, так что да.

Можно ли на JavaScript разрабатывать приложения под Android, которые могли бы выйти на мировой уровень?

Можно но дороже и сложнее чем на Java (профит только при суппорте хотя бы двух платформ). Еще есть native-react из интересного.

Точно не второй вариант, в нем нет смысла ни для машины ни для человека.

Разницы между 1-ым и 3-им вариантов особо нет, поисковики прекрасно умеют переводить ключевые слова и учитывать это при поиске. Для человека урл в большинстве случаев так же бесполезен, никто не пишет их руками, только разработчики и SEO-шники страдают подобным. Насколько я понимаю логика довольно проста, если ключевое слово входит в урл, то в ранжировании оно будет выше чем перевод. Так если вы ищите "page" то 3-ий вариант, а если "страница" то 1-ый. Хотя опять же у меня нет информации о том насколько велика разница с учетом остальных параметров (у вас же не только урл влияет на все это, а вообще все, от банально метатегов и ключевых слов в тексте до оптимизации фронтэнда и поддержки мобильных устройств).

Если я не прав, требую прув.