Алексей П: да я как бы и не парюсь, мне D больше нравится) Я к тому что называть на данном этапе Rust недоделанным как-то слишком громко. Насколько я помню у них только API для работы с I/O будет меняться еще до бэты и понятно что пока рано в продакшен писать, но вроде как ближайшие пару месяцев стандартизируют API а пока этого не произошло - можно его поизучать/потыкать.
В любом случае применение в WEB подобных вещей просто так, потому что захотелось, глупо.
Андрей Петров: JS - демоны, обмен данными между клиентом и основным приложением. Если вам надо что-то считать много или чего тяжелого делать - лучше взять что-то другое. Node хорош когда работы которую будет выполнять мало, и нужно обрабатывать много запросов. Скажем доставку уведомлений, работа с I/O через очереди просто шикарно работает на event loop.
Алексей П: и да, у этих языков чуть чуть различаются сферы применения. Rust - для системного программирования. Чисто теоритически сейчас это единственный прямой конкурет C++. Скажем у D в плане стабильности и зрелости все чуть печально. Golang же именно для разработки распределенных приложений придумывался насколько я помню.
Алексей П: Откуда вы беретесь со своими гигрометрами? Вышла вот недавно первая альфа 1.0, то есть большая часть API уже стабилизирована. Где-нибудь в марте уже будут более мение стабильные бэты которые уже можно будет использовать для серьезной разработки. Релиз вроде грозятся сделать уже летом.
По моему опыту лучше сразу заморочиться и заюзать какой VichUploaderBundle (или что там сча модно) ибо потом клиент или нужды проекта потребуют хранить файлы на Amazon s3 или в любом другом облаке, может еще какая хитрая логика появится или должна быть поддержка своих серверов для статики... А так мы абстрагируемся от проблем в будущем.
Единственное что мне лично не нравится VichUploaderBundle а ничего лучше на данный момент я не знаю. Даже думал как-то форкнуть и переделать не нравящиеся мне места.
Юзать же трейты для полей моделей я не особо люблю потому что.... это модели, сущности... я лучш сделаю бандл предоставляющий мне отдельную сущность File чем буду лепить дополнительные поля к моей красивой модельке.
vasIvas: тут важно понимать еще контекст задачи. Скажем в backend разработке модель крайне редко должна нотифаить вью о том что она поменялась так как все изменения происходят в рамках запроса. Именно по этому на сервере никогда почти не применяют чистый MVC хотя и называют это MVC.
В дескптопных приложениях все чуть веселее. Там да, вью может обновлять себя в ответ на изменение модели по событиям. В этом случае MVC себя показывает не очень так как модель должна помимо бизнес логики еще и уведомлять всех и вся, увеличивается связанность и т.д. С другой стороны контроллер выполняет крайне мало обязанностей, по сути его задача в контексте UI приложения обрабатывать ввод пользователя и передавать в модель, связывать модель и представление (я имею ввиду говорить какое представление для модели использовать в данный момент). Потому и были добавлены схемы типа MVP/MVVM которые вносят еще один слой чья задача как раз таки связывание данных между моделью и представлением, нотификация вью об изменениях модели и т.д.
Юрий Левин: ну потому что два года с ними жил, тоже думал что "удобно, все в одном месте, если добавил/удалил поле не забудешь мэппинги поправить и все такое" а по факту... в тех же сущностях частенько бывает что наследование используется и уже не так все просто, а еще бывает так что у тебя в сущности 5 полей и вместо 5-ти строк + phpdoc к ним, вырисовывается еще + 3-4 аннотации на каждое поле. А если еще HateoasBundle какой помимо JMSSerializer, валидаци, еще чего полезного и все... Так же меня напрягает сейчас что аннотации для ввалидации/мэппингов и прочего требуют слишком много действий. Скажем для JmsSerializer держать конфиги в yml намного приятнее и пока проблем с тем что оно лежит в двух местах (поля и настройки для них) у меня лично не было. Зато можно всегда узнать откуда эти параметры применяются, конфиги легко читаются и исключительно для того, для чего они нужны.
Еще крайне забавным для себя считаю проектирование системы через DDD+BDD, Behat и все такое. Настолько упоролся сейчас этими идеями что начал писать тулзу для моих QA что бы они мне фичаспеки писали и для ручного тестирования использовали. Что-то типа testlink-а только адекватное и под мои нужды. А уже по фичаспекам писать код начиная с предметной области (по сути интеграционные тесты пишу по спекам) и только когда готовы все сервисы приступаю к контроллерам. Это ограничивает разработчика от желания наговнокодить в контроллерах.
Юрий Левин: Я последние пол года избегаю использовать аннотации внутри сущностей (да и вообще только в контроллерах разрешаю для себя) - получается намного удобнее.
Юрий Пузыня: Новость замечательная, но а как на фронтэнде, если не секрет? Насколько я знаю там тоже все не так радужно. Мне понравилось как при помощи zone.js это можно хэндлить, но все же?
algor0545: вы о чем вообще? В каком таком низком качестве? Вот честно, никогда с ними проблем небыло. Может вы в JPG сохраняли или в настройках со сжатием переборщили?
lileil: сокен отличается. Да и процессоры впаяны.. как бы... в ноутах... так что самостоятельно у вас просто не выйдет заменить процессор. только вместе со всем железом.
