При фрилансе, конечно не изменилось, кроме решаемых траблов с переводами/регистрацией ничего и не поменялось. Я говорю про средние по больнице зарплаты в отрасли (читайте «работа в бодишопах/аутсорсах/etc»).
Ээ, с зарплатой как бы тема нераскрыта: сейчас всех, кто раньше получал $3+ можно хантить на 1-1.5 еще и рады остаются.
P.S. Сам уехал, но с ситуацией знаком, ибо много знакомых остались.
Вообще это костыли, без нормального конфигурейшн-менеждера ни одно приложение не взлетит. Специально под докеры заточены www.ansible.com/home
Все остальное — это «я написал сайт и запихну его в докер, потому что это модно».
Перевод из хелпа оракла, конечно, очень полезен. Рассказали бы лучше про какие-нибудь трики вещи, вроде distributed transaction, compensation processes, dehydration points.
Активное использование хранимок достаточно распространено при построении систем на базе CQRS подхода, но даже там не идет полный перенос БЛ на базу. Это, скорее, наследние старых времен.
Я не говорю, что стоить сразу писать приложение с учетом нагрузки как у гугла или фейсбука и пихать везде мезос, но в современном мире существует достаточно много паттернов проектирования, сводящих необходимость переписывания или овер-инжениринга к минимуму. Те же SOA/Microservices не требуют дополнительных усилий, но позволяют заранее застраховаться от многих проблем в будущем.
На тему прототипа, прототип — это прототип. Никто в здравом уме не будет допиливать продукт, который склепал Вася, а оставят его как паблик альфу и сбоку с нуля построят нормальное решение. Но прототип, MVP, PoC или как хотите его назовите — это не более, чем оценка интереса таргет аудитории, а никак не «болванка» для системы, которая пойдет в продакшн. ОК, возможно какой-нибудь сайт на вордпресе и можно дотянуть из прототипа, но в контексте статьи мы говорим о системах с более высокой сложностью.
Плюс интересует каким образом архитектура, придуманая на стадии концепции (когда не известно ни поведение системы под нагрузкой, ни собтсвенно сам характер нагрузки) поможет чего-то избежать
Вы, надеюсь, не серьезно? Вообще-то поведение системы под нагрузкой является как раз одним из входных параметров, при проектировании систем, а не «потом сбоку докрутим, чтобы не лагало».
Мало, как правильно указали выше, результатом статьи стало что-то, что назвали «красивой схемой архитектуры». По факту это просто орнаменты по мотивам визио, которые красиво смотрятся в презентации заказчикам из не-IT сферы, но не тянут на громкий заголовок.
Кстати, SEI, пожалуй, единственные, кто пытаются стандартизировать подходы в проектировании систем (вернее, пытаются-то не единственные, но единственные, кто преуспели). Достаточно действенен тот же самый Quality Attribute Workshop, который позволяет в сжатые сроки сдоить с холдеров дополнительные критерии.
Ну, как IDE никто не мешает использовать ту же idea, например. Про support не соглашусь, реагируют в течении бизнес дня, возможно, зависит от типа лицензии
Конкретно по ценам не скажу, это зависит от клиента. В целом надо понимать, что использовать Kony для «просто проложений» — это палить из пушки по воробъям.
Основной фишкой является вся инфраструцтура в целом (например, middleware, которий можно деплоить под WebShpere и он будет хендлить все клиентские сервисы, за счет кластеризации сферы все очень просто масштабируется).
Новым направлением является Cloud — provisioning енва делаэтся по клику мышки, деплой — еще по одному.
Из проблем: нет контролов (т.е. с точки зрения UI прийдется много копипастить), вменяемий MVP framework будет только в следуюшей major версии, про аналитку — это рекламный ход (реализовивать прийдется самому через FFI), маленькоe community — в основном enterprise сектор (но достаточно бистрый и адекватный support), иногда встречаются весьма экзотическиe баги на фикс которых уходит много времени (необходимо связываться с сапортом, шарить логи etc.)
В целом, я бы сказал, если нет цели использовать всю инфраструктуру коней, лучше используйте Xamarin или native :)
Sorry for English — don't want to use transliteration. Info about Kony not full, prices are not actual (they're Kony cloud prices and cloud is SaaS). If someone interested — can go into details. Disclaimer: I'm not a Kony employee :)
Это недорого :) Для сравнения, отель в SF стартует от $200, а тут за 2 дня еще и с едой.
По теме — надо попробовать записаться, если получится, расскажу о впечатлениях :)
Одна из трудностей документа архитектуры – частые изменения. И здесь нет однозначной методики контроля и ведения истории данных изменений
Вообще-то есть :) Смотрите SEI, у них есть даже отдельный курс про документацию.
В целом по тексту, сложилось впечатление, что автор романтизирует профессию и считает, что архитектор такой себе «вольный художник». На практике, такое возможно только в маленьких проектах. Все остальное давно формализовано, существуют подходы по вычленению наиболее важных quality attribute'ов, фреймворки для нахождения architecture trade off'ов и т.п. По факту, архитектор в современном мире — это человек, грамотно проецирующий свой багаж знаний (и умеющий его быстро пополнить, если необходимо) на конкретную проблему, при помощи разработанных подходов, а-ля best practices.
Не совсем, сами по себе саги и стейт-машин саги (которые, кстати, вроде уже заменены на magnum от того же автора) — это просто обвязка. А так, каждый инстанс саги может хранится в базе, например.
Не вполне корректное сравнение. ENQ — это простая обертка над API, вкусный роутинг. MT — не просто роутинг, и Саги, как Вы заметили, но еще и сохранение стейта объектов. Как следствие, возможность построить нормальные workflow.
P.S. Сам уехал, но с ситуацией знаком, ибо много знакомых остались.
Все остальное — это «я написал сайт и запихну его в докер, потому что это модно».
На тему прототипа, прототип — это прототип. Никто в здравом уме не будет допиливать продукт, который склепал Вася, а оставят его как паблик альфу и сбоку с нуля построят нормальное решение. Но прототип, MVP, PoC или как хотите его назовите — это не более, чем оценка интереса таргет аудитории, а никак не «болванка» для системы, которая пойдет в продакшн. ОК, возможно какой-нибудь сайт на вордпресе и можно дотянуть из прототипа, но в контексте статьи мы говорим о системах с более высокой сложностью.
Вы, надеюсь, не серьезно? Вообще-то поведение системы под нагрузкой является как раз одним из входных параметров, при проектировании систем, а не «потом сбоку докрутим, чтобы не лагало».
Конкретно по ценам не скажу, это зависит от клиента. В целом надо понимать, что использовать Kony для «просто проложений» — это палить из пушки по воробъям.
Основной фишкой является вся инфраструцтура в целом (например, middleware, которий можно деплоить под WebShpere и он будет хендлить все клиентские сервисы, за счет кластеризации сферы все очень просто масштабируется).
Новым направлением является Cloud — provisioning енва делаэтся по клику мышки, деплой — еще по одному.
Из проблем: нет контролов (т.е. с точки зрения UI прийдется много копипастить), вменяемий MVP framework будет только в следуюшей major версии, про аналитку — это рекламный ход (реализовивать прийдется самому через FFI), маленькоe community — в основном enterprise сектор (но достаточно бистрый и адекватный support), иногда встречаются весьма экзотическиe баги на фикс которых уходит много времени (необходимо связываться с сапортом, шарить логи etc.)
В целом, я бы сказал, если нет цели использовать всю инфраструктуру коней, лучше используйте Xamarin или native :)
По теме — надо попробовать записаться, если получится, расскажу о впечатлениях :)
Вообще-то есть :) Смотрите SEI, у них есть даже отдельный курс про документацию.
В целом по тексту, сложилось впечатление, что автор романтизирует профессию и считает, что архитектор такой себе «вольный художник». На практике, такое возможно только в маленьких проектах. Все остальное давно формализовано, существуют подходы по вычленению наиболее важных quality attribute'ов, фреймворки для нахождения architecture trade off'ов и т.п. По факту, архитектор в современном мире — это человек, грамотно проецирующий свой багаж знаний (и умеющий его быстро пополнить, если необходимо) на конкретную проблему, при помощи разработанных подходов, а-ля best practices.