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

пройтись циклом по каждому ряду и удалить первый td. А еще можно взять через querySelectorAll вообще все первые td-шки и удалить тоже в цикле.

function MyCustomInputDirective () {
    return {
        require: 'ngModel',
        link: function (scope, el, attr, ngModelController) {
             // ... а тут происходит магия
        }
    };
}

1) stackoverflow.com/questions/843972/image-compariso...
2) по второй теме материалов настолько много, что лучше просто погуглить. Есть и готовые решения, и не одно, и на разных языках...

CORS

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

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

Короче все сводится к такому параметру как maintainability.

https://github.com/phptodayorg/php-must-watch#arch...

updated
если интересно, есть пример "хорошей" архитектуры (ну или основы для нее), ну или как минимум интересной:
https://github.com/qandidate-labs/broadway

Конечно этот пример не подходит для всех предметных областей, но как один из вариантов "посмотреть как люди делают" - как по мне неплохо.

Лучше прочесть что и как делать.

Такого нет. Почитайте книжку с носорогом.

Роман Вакульчик: начнем с того что поиск в базе регулярками это плохая идея. Есть всякие там сфинксы, эластик серчи и т.д. у которых есть вполне себе приличная индексация текста.

Опишите задачу более конкретно. Пока все варианты медленнее и самый быстрый - держать данные в памяти (СУБД, массивы, как хотите) и искать там. Сложность поиска будет все-равно O(N).

Если мне лень заморачиваться по поводу верстки и дизайна - bootstrap (подумываю посмотреть в сторону angular material).

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

У вас страница генерится аж 4.5 секунд. Что ж вы хотите? Ищите разработчика что бы тот оптимизировал. Много чего можно сделать что бы в короткие (относительно) сроки вклинить кэш... Может быть вам просто PHP надо обновить или может не установлен APC/OpCache... Может в базе индексы не расставлены (в любом случае кеширование стоит сделать).

мне казалось что все что не .on помечено как deprecated...

В любом случае:
- .on - универсальный метод объеденяющий все ниже перечисленные. Всегда старайтесь использовать его.

- .live - вешает листенер на document и проверяет источник события. Гуглить "Всплытие событий". Был еще .delegate, который делал ровно то же самое но вы сами указывали ноду на которую вешается обработчик. А теперь вопрос, что будет быстрее? Вешать обработчик напрямую на элемент или на его родителя и проверять с какого элемента этот ивент всплыл? Будет ли разница по глубине DOM дерева? Если мы дошли что чем ближе обработчик висит к целевой ноде, тем быстрее, почему вообще нужно использовать делегирование событий? Помимо упрощения работы (если DOM поменялся обработчики не нужно перерегистрировать так как контейнер не менялся и все еще хранит листенер) есть еще такой параметр как количество листенеров. Если у вас табличка аля эксель, проще повесить один листенер на контейнер чем много-тысяч на каждую ячейку.

- .bind - просто вешает событие на элемент.

- .click - алиас для .bind('click').

if (api.hasOwnProperty('attachmens') && Array.isArray(api.attachments)) {
    api.attachments.forEach(function (attacment) {
    
    });
}

Но судя по примеру кода который вы предоставили - подумайте в сторону использования шаблонов на клиенте. Жить будет проще.

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

var tpl = {
    photo: ''tpl for photo,
    audio: 'some other tpl'
};

Почитайте про функции-конструкторы. Вы не можете применить new к хэш-мэпе. http://learn.javascript.ru/object-methods#функция-...

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

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

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

MVVM, MVP и т.д. это дальнейшее развитие MVC. По сути чем больше слоев и уже специализация оных - тем меньше связанность кода. Например в Angular связь между контроллером и вьюшкой поддерживает отдельный слой ($scope) - грубо говоря это ViewModel. Ну и т.д.

Словом... лучше напишите что уже пробовали и чем вас так не устраивает MVC и зачем вы вообще загоняетесь на эту тему?

Организуйте шину данных на каком RabbitMQ/ZeroMQ. И все. PHP паблишит в очередь сообщение - нода обрабатывает - паблишит в другую очередь другое сообщение - PHP принимает.

Вконтактик использует long polling вместо websockets. Это так, к слову. Да и лицокнига тоже.

https://github.com/tamaspiros/advanced-chat - я думаю готовый чатик с большей частью функционала должны натолкнуть вас на ответ.

socket.io - только транспорт. Логику придется реализовывать самостоятельно.

все что хоть сколько нибудь сложнее простеньких ng-show/ng-hide, или простых обходов цикла скорее всего следует делать не в темплейтах а в контроллере.