Я только с гитлаб CI месяца два игрался. Вам, кстати, дико повезло. Они сильно прокачались за последний год.
А транскодер амазоновский юзали? Тормознутый или дорогой?
Кстати, какой расклад по железу? Сколько процов и озушки на прод окружение потребовалось? И если не секрет, какие счета выставили облачные провайдеры? Такое ощущение, что 93% конечного чека составила плата за траффик.
В нашем мире нет ничего идеального, и GraphQL тому хороший пример. Но черт побери, даже сейчас эта шарманка хорошо ускоряет разработку большинства клиент-серверных приложений. Но опять-таки надо исходить из бизнес задач, кому-то GraphQL может не подойти или не зайти.
С месяца два-три назад у меня стоял выбор между Angular и React.
React безоговорочно победил — чуваки все делают явно и понятно, походу допиливают будущий ява-скрипт ES7, ES8. www.youtube.com/watch?v=4anAwXYqLG8
А если взять и посмотреть на Relay и GraphQL, то эти штуки вообще долбасят ангуляр тяжелой артиллерией с бэкенда.
GraphQL — это замена старому доброму REST (уже прекрасный и эталонный api github'а стал стар). Можно забыть про версионность API: youtu.be/WQLzZf34FJ8?t=12m52s
Relay — это обработчик, который вяжет React компоненты с данными из GraphQL.
Он просто позволяет собрать весь сторонний ява-скрипт (счетчики) в один файл. Туда можно еще кучу всяких отслеживаний событий для аналитикса засунуть, код для A/B тестирования и прочее.
Обычно всякие SEO агентства просят его установить, чтобы потом спокойно добавлять/убирать ява-скрипт, не прибегая к разработчикам.
Отличная статья.
Сами сталкивались с кучей узких мест по производительности и отрисовке. Очень страдали от инпутов в контенте и свайпа меню — в результате отказались от андроидов 2.3.
1) Смотрели ли вы в сторону Angularjs вместо Backbone?
Сам тяготел к backbone, пока не заставили посмотреть 12-минутное видео (http://www.youtube.com/watch?v=WuiHuZq_cg4) про построение To-Do листа на ангуляре. Сразу для меня померкли мульки MVC от бэкбона.
2) Почему RAD.js? Пробовали вместо него взять marionettejs для бэкбона?
Я говорю не про производительность работы скриптов на серверах. Симфони в продакшене показывает оличную скорость.
Я говорю про удобство работы программистов с фреймворком, про стоимость разработки на нём и стоимости поддержки. Про то насколько сложно будет ввести в курс дела нового программиста.
Если честно, то мы ужасно намучились за 2 месяца разработки на ней. На ней нереально сложно разрабатывать свои бандлы.
Тьфу-тьфу-тьфу, пожалуйста не накаркайте :) про то, что через 2 месяца мы будем то же самое говорить про руби. Нам надо выпустить проект в январе.
— про удобные редакторы:
Нас три человека, и у каждого из нас свой «любимый» редактор IDE: Eclipse, NetBeans, SublimeText2. Поэтому нет никаких проблем в работе с кодом. Просто лишком навернутое абстрагирование классов друг от друга. С одной стороны это огромный плюс для Симфони, но и в то же время минус (в голове всё удержать тяжело).
— про сервисы:
Проблем с написанием сервисов никаких. Просто при разработке аналогичного друпаловскому модулю — Content Construction Kit (CCK) нам пришлось навернуть порядка 20 сервисов для того, чтобы обеспечить работу параметров через стандартный механизм форм и валидации. Сколько в итоге для всего этого написали классов тяжело поддаётся подсчёту. Безумный симфонийский уровень абстракции начал играть с нами — просить написать пару тройку классов для одной задачи.
— про ошибки:
Самая основная проблема в том, что в режиме разработчика приходится долго ждать пока сгенерится страница. Сделал опечатку, жди 10-40 секунд пока прогрузится страница. Подправил, в другом месте ошибка — опять жди. Понятно, что в продакшене всё это дело будет быстро работать, но в dev режиме скорость работы просто ужасна.
Да вы правы про то, что мы недоразобрались. Но сколько уже можно разбираться?!
Поэтому с тем, что мы необъективны я с вами не соглашусь. Для меня объективно важна скорость ввода нового человека в проект. К сожалению, всё достаточно сложно (да вроде всё логично и понятно, НО в голове приходится держать слишком огромную модель взаимосвязей). А сам фреймворк должен помогать, а не мешать.
Честно, когда я увидел описание симфони, попробовал квик-старт — я был впечатлен. Мне все очень понравилось. И понравился отладчик и магия DI. Это казалось очень простым и удобным функционалом. Потом мы заюзали композер, прикрутили Capifony, жизнь разработчика, как бы стала ярче. Теперь для разворачивания новой версии на продакшене занимало всего одну команду. Все было круто, симфони ушел намного вперёд по сравнению с остальными фреймворками.
Прошло время, и мы стали понимать, что фреймворк тормозит нашу работу. По первой, мы думали, что просто стары стали. Что надо перестраивать мозг. Потеряли хватку. Что вот-вот и придёт прозрение. Что ещё чуть-чуть и нирвана поглотит нас. В какой-то момент у нас одновременно у троих лопнуло терпение. Сели, поговорили, и вынесли для себя вердикт — спрыгнуть побыстрее со всей этой магии, абстракции и модульности. Мы потеряли контроль, контроль над ошибками, контроль над определением сроков.
3 года разрабатывали на ZF. Решили 2 месяца назад перейти на симфони. Все свои наработки портировали, стали разрабатывать свои бандлы. И через 2 месяца терпение кончилось:
— миллионы классов
— не знаешь как написать, создавай сервис
— конфиги в разных местах
— чтобы найти или исправить ошибку, нужно минимум пол дня
Для себя прояснили:
— что стоимость разработки и поддержки на порядок выше,
— полно магии, да не просто магии, а чёрной магии, которая капитально связывает руки разработчикам
— документация хороша ровно до определенного момента, полно примеров, но как только нужно что-то похожее не из примеров, то документация этого не описывает и приходится лезть в исходники, чтобы понять как что-то реализовать
— DI и EventListeners это вроде бы клёво, но поверьте, дебаггинг с такими наворотами просто заставляет рвать волосы на голове, а если открыть чужой код, то он будет реально тяжел в понимании
Может быть использование только контроллеров и экшенов там удобно и те, кто этим ограничится будут счастливы.
Но только стоит начать писать свои бандлы, и ты понимаешь насколько больные явой люди писали этот код.
Чес слово, реальная ценность в простых вещах. К сожалению, у симфони её очень мало.
Дабы не портить свою жизнь, мы отказались от Symfony 2. И что ужасно — теперь не хотим возвращаться обратно в ZF.
Сейчас с PHP в тестовом режиме переходим на Ruby. В рельсах тоже много магии, но надеемся, что она будет белой.
Просто сами активно ZF используем, и как-то у нас отвалились запросы к API (получали пустой ответ от сервера, как потом оказалось в php memory_limit не хватало).
Пока выясняли, залез в код и приятно так на душе стало, что Plesk начал юзать ZF. А то страшновато доверять приложению с закрытым исходным кодом. А тут понимаешь что код написан по стандартам и достаточно сложно написать говноприложение используя ZF.
А интеграцию делали для управления шаред-хостингом через их стандартный API для панели WHMCS.
Молодцы. Интересно в 11 версии они полностью перешли на Zend Framework в интерфейсе админа и клиента?
А то в 10 симбиозная каша из зенда и старого движка.
Большие молодцы!
Я только с гитлаб CI месяца два игрался. Вам, кстати, дико повезло. Они сильно прокачались за последний год.
А транскодер амазоновский юзали? Тормознутый или дорогой?
Кстати, какой расклад по железу? Сколько процов и озушки на прод окружение потребовалось? И если не секрет, какие счета выставили облачные провайдеры? Такое ощущение, что 93% конечного чека составила плата за траффик.
В нашем мире нет ничего идеального, и GraphQL тому хороший пример. Но черт побери, даже сейчас эта шарманка хорошо ускоряет разработку большинства клиент-серверных приложений. Но опять-таки надо исходить из бизнес задач, кому-то GraphQL может не подойти или не зайти.
С удовольствием жду продолжения!
С месяца два-три назад у меня стоял выбор между Angular и React.
React безоговорочно победил — чуваки все делают явно и понятно, походу допиливают будущий ява-скрипт ES7, ES8. www.youtube.com/watch?v=4anAwXYqLG8
А если взять и посмотреть на Relay и GraphQL, то эти штуки вообще долбасят ангуляр тяжелой артиллерией с бэкенда.
GraphQL — это замена старому доброму REST (уже прекрасный и эталонный api github'а стал стар). Можно забыть про версионность API: youtu.be/WQLzZf34FJ8?t=12m52s
Relay — это обработчик, который вяжет React компоненты с данными из GraphQL.
Он просто позволяет собрать весь сторонний ява-скрипт (счетчики) в один файл. Туда можно еще кучу всяких отслеживаний событий для аналитикса засунуть, код для A/B тестирования и прочее.
Обычно всякие SEO агентства просят его установить, чтобы потом спокойно добавлять/убирать ява-скрипт, не прибегая к разработчикам.
play.google.com/store/apps/details?id=kz.ps.app
Логин: demo
Пасс: demo
Отказываться от титаниума в пользу фонгап собираетесь?
Сами сталкивались с кучей узких мест по производительности и отрисовке. Очень страдали от инпутов в контенте и свайпа меню — в результате отказались от андроидов 2.3.
1) Смотрели ли вы в сторону Angularjs вместо Backbone?
Сам тяготел к backbone, пока не заставили посмотреть 12-минутное видео (http://www.youtube.com/watch?v=WuiHuZq_cg4) про построение To-Do листа на ангуляре. Сразу для меня померкли мульки MVC от бэкбона.
2) Почему RAD.js? Пробовали вместо него взять marionettejs для бэкбона?
И wowik молодец, постоянно там что-то крутил на картах.
Даже когда он доступ потерял, появился IWowik (а может он на мак пересел).
Я говорю про удобство работы программистов с фреймворком, про стоимость разработки на нём и стоимости поддержки. Про то насколько сложно будет ввести в курс дела нового программиста.
Если честно, то мы ужасно намучились за 2 месяца разработки на ней. На ней нереально сложно разрабатывать свои бандлы.
Просто мы видимо слишком много от нее требуем, и мало хотим ей отдавать, и у нас любовь с Symfony2 не сложилась.
Их гораздо удобнее расширять чем ZF. Zend_Form полная какашка, так же как и Zend_Db.
Во всех планах Symfony 2 сейчас впереди всех php-шных фреймворков.
— про удобные редакторы:
Нас три человека, и у каждого из нас свой «любимый» редактор IDE: Eclipse, NetBeans, SublimeText2. Поэтому нет никаких проблем в работе с кодом. Просто лишком навернутое абстрагирование классов друг от друга. С одной стороны это огромный плюс для Симфони, но и в то же время минус (в голове всё удержать тяжело).
— про сервисы:
Проблем с написанием сервисов никаких. Просто при разработке аналогичного друпаловскому модулю — Content Construction Kit (CCK) нам пришлось навернуть порядка 20 сервисов для того, чтобы обеспечить работу параметров через стандартный механизм форм и валидации. Сколько в итоге для всего этого написали классов тяжело поддаётся подсчёту. Безумный симфонийский уровень абстракции начал играть с нами — просить написать пару тройку классов для одной задачи.
— про ошибки:
Самая основная проблема в том, что в режиме разработчика приходится долго ждать пока сгенерится страница. Сделал опечатку, жди 10-40 секунд пока прогрузится страница. Подправил, в другом месте ошибка — опять жди. Понятно, что в продакшене всё это дело будет быстро работать, но в dev режиме скорость работы просто ужасна.
Да вы правы про то, что мы недоразобрались. Но сколько уже можно разбираться?!
Поэтому с тем, что мы необъективны я с вами не соглашусь. Для меня объективно важна скорость ввода нового человека в проект. К сожалению, всё достаточно сложно (да вроде всё логично и понятно, НО в голове приходится держать слишком огромную модель взаимосвязей). А сам фреймворк должен помогать, а не мешать.
Честно, когда я увидел описание симфони, попробовал квик-старт — я был впечатлен. Мне все очень понравилось. И понравился отладчик и магия DI. Это казалось очень простым и удобным функционалом. Потом мы заюзали композер, прикрутили Capifony, жизнь разработчика, как бы стала ярче. Теперь для разворачивания новой версии на продакшене занимало всего одну команду. Все было круто, симфони ушел намного вперёд по сравнению с остальными фреймворками.
Прошло время, и мы стали понимать, что фреймворк тормозит нашу работу. По первой, мы думали, что просто стары стали. Что надо перестраивать мозг. Потеряли хватку. Что вот-вот и придёт прозрение. Что ещё чуть-чуть и нирвана поглотит нас. В какой-то момент у нас одновременно у троих лопнуло терпение. Сели, поговорили, и вынесли для себя вердикт — спрыгнуть побыстрее со всей этой магии, абстракции и модульности. Мы потеряли контроль, контроль над ошибками, контроль над определением сроков.
3 года разрабатывали на ZF. Решили 2 месяца назад перейти на симфони. Все свои наработки портировали, стали разрабатывать свои бандлы. И через 2 месяца терпение кончилось:
— миллионы классов
— не знаешь как написать, создавай сервис
— конфиги в разных местах
— чтобы найти или исправить ошибку, нужно минимум пол дня
Для себя прояснили:
— что стоимость разработки и поддержки на порядок выше,
— полно магии, да не просто магии, а чёрной магии, которая капитально связывает руки разработчикам
— документация хороша ровно до определенного момента, полно примеров, но как только нужно что-то похожее не из примеров, то документация этого не описывает и приходится лезть в исходники, чтобы понять как что-то реализовать
— DI и EventListeners это вроде бы клёво, но поверьте, дебаггинг с такими наворотами просто заставляет рвать волосы на голове, а если открыть чужой код, то он будет реально тяжел в понимании
Может быть использование только контроллеров и экшенов там удобно и те, кто этим ограничится будут счастливы.
Но только стоит начать писать свои бандлы, и ты понимаешь насколько больные явой люди писали этот код.
Чес слово, реальная ценность в простых вещах. К сожалению, у симфони её очень мало.
Дабы не портить свою жизнь, мы отказались от Symfony 2. И что ужасно — теперь не хотим возвращаться обратно в ZF.
Сейчас с PHP в тестовом режиме переходим на Ruby. В рельсах тоже много магии, но надеемся, что она будет белой.
Рейтинг = Нижняя граница доверительного интервала Вильсона (Wilson) для параметра Бернулли
И тут я докрутил до формулы — и лег под стол. Посмеялся от души!
Материал отличный! Буду вспоминать математику и тестировать.
Спасибо.
+1 в карму ;)
Пока выясняли, залез в код и приятно так на душе стало, что Plesk начал юзать ZF. А то страшновато доверять приложению с закрытым исходным кодом. А тут понимаешь что код написан по стандартам и достаточно сложно написать говноприложение используя ZF.
А интеграцию делали для управления шаред-хостингом через их стандартный API для панели WHMCS.
А то в 10 симбиозная каша из зенда и старого движка.
Представляете перевод домена алтын.қаз — золотой гусь. Можно еще вагон весёлых названий напридумывать.
Вобщем гусиная зона получается.