Вот и до меня довезли "олени" подарочек от Дедушки! Спасибо Деда за подарочек, каждый раз хотел себе купить такой, но останавливался с мыслью, что обычный, что у меня есть, покрывает все нужды. И, о чудо! Деда прислал новенький, теперь мне все по плечу!
Фух…
Вот и я добрался до новогодних оленей и забрал там свой подарочек. Теперь-то я точно знаю чем буду занят в новогодние праздники!
Спасибо Дедушка!!!
Ну а если серьезно, обычно бывает так: "Давайте быстро запилим прототип чтобы проверить" — делают. И потом не могут выпилить. Ну и в целом прог вхождения в vaadin — не очень то уж и большой. Поэтому имеем, что имеем.
Ну и второй пункт, что с помощью vaadin — нельзя делать публичные интерфейсы, т.к. оно не про нагрузки. А вот рисовалки форм для бизнес логики, чтобы данные из таблички на форму и обратно гонять — самое то!
Что-то я затянул с отчетом о подарке в этом году, но все же пишу. Спасибо тебе дедушка за подарок! Все оказалось к месту!!! Игрушки на елке, мышка под ёлкой, браслет на руке, а VMware гордо красуется на столе!
Ну я не знаю, после освоения вима, вопросов с освоением i3 не встало (предлагаю попробовать еще раз с этой вот инструкцией ). Единственное, надо было подпилить напильником, в течение месяца после запуска.
Но! Теперь конфиг мигрирует со мной по всем тачкам из гита, и везде одинаковое окружение получается, что не может не радовать.
Спасибо за развернутый ответ!
Единственное, по 1-му пункту, свои "пять копеек". Связка i3wm+vim перекрывает все вопросы работы с файловой системой, проектами, множеством мониторов и прочие плюшки, и почти не надо пользоваться мышкой))
Мощно! Идея не приходила в голову, но в свое время очень сильно удивился про ограничение для клиента в 1.5 гб на файл. Писал клиента telegram для backup'ов, который синхронизировал файлы из определенной директории в заданный чат.
Надеюсь что ваш проект получит дальнейшее развитие!
PS
Для помощи оформили бы issues для людей "не в теме" как помочь проекту.
Простые модели — не всегда интересно. А можно примеры сборок, да ещё и перестраиваемых?))
Ну или хотя бы примеры кода с взаимосвязями (сопряжения) тел в модели.
А в целом — этого мне не хватало лет 5 назад очень сильно.
Правда я так и не разобрался, почему у меня перестали гореть лампочки, но я обязательно это починю, а пока перемычка ;)
PS
Давно хотел заняться DIY, деда меня подтолкнул к этому. Деда, надеюсь у тебя все хорошо))
В общем, отрывать бизнес логику от транспорта это хорошая идея, но не везде применимая.
С этим пунктом полностью согласен, тут не будет "серебряной пули".
нужно выводить с какого IP пришёл запрос, от имени какого юзера/с какими правами выполняется, ну и да, вызванный метод нужно тоже выводить, причём очень хочется чтобы за это отвечала одна строка кода в слое работы с RPC,
Не всегда сервис бывает верхнеуровневым, чтобы в нем можно было отследить данные по IP и прочее, я думаю этот кейс лучше будет решаться с помощью сквозного ID для запроса.
Волшебно. Т.е. если у нас меняются данные бизнес логики то это автоматически изменит данные бегающие по RPC. Ну да, совместимость API это для слабаков.
Наверное в случае с применением паттерна микросеврис, будет проще поддерживать активными 2 экземпляра сервисов с разным API и делать роутинг запросов на них.
Резюмируя: каждый раз, когда я читаю что-то по Go kit, у меня возникает впечатление, что он реализует гибкость немного не в том месте, где она реально нужна. Может дело не в Go kit, а в том как им пользуются, но вообще тенденция немного настораживает.
Отдать должное, я в целом поддерживаю подход автора статьи, но с удовольствием посмотрел бы на другой способ применения Go kit при разработке миркосервисной архитектуры. Хотя может в случае элегантного монолита проблем описанных выше, было бы меньше.
PS powerman если у вас есть опыт разработки микросервисов с помощью какого либо toolkit или framework, а может быть и без, могли бы им поделиться?
Вот и до меня довезли "олени" подарочек от Дедушки! Спасибо Деда за подарочек, каждый раз хотел себе купить такой, но останавливался с мыслью, что обычный, что у меня есть, покрывает все нужды. И, о чудо! Деда прислал новенький, теперь мне все по плечу!
Новый "Подарочек"!
Вот и я добрался до новогодних оленей и забрал там свой подарочек. Теперь-то я точно знаю чем буду занят в новогодние праздники!
Спасибо Дедушка!!!
Это даже кто-то читает xD
Ну а если серьезно, обычно бывает так: "Давайте быстро запилим прототип чтобы проверить" — делают. И потом не могут выпилить. Ну и в целом прог вхождения в vaadin — не очень то уж и большой. Поэтому имеем, что имеем.
Ну и второй пункт, что с помощью vaadin — нельзя делать публичные интерфейсы, т.к. оно не про нагрузки. А вот рисовалки форм для бизнес логики, чтобы данные из таблички на форму и обратно гонять — самое то!
Что-то я затянул с отчетом о подарке в этом году, но все же пишу. Спасибо тебе дедушка за подарок! Все оказалось к месту!!! Игрушки на елке, мышка под ёлкой, браслет на руке, а VMware гордо красуется на столе!
Ну я не знаю, после освоения вима, вопросов с освоением i3 не встало (предлагаю попробовать еще раз с этой вот инструкцией ). Единственное, надо было подпилить напильником, в течение месяца после запуска.
Но! Теперь конфиг мигрирует со мной по всем тачкам из гита, и везде одинаковое окружение получается, что не может не радовать.
Спасибо за развернутый ответ!
Единственное, по 1-му пункту, свои "пять копеек". Связка i3wm+vim перекрывает все вопросы работы с файловой системой, проектами, множеством мониторов и прочие плюшки, и почти не надо пользоваться мышкой))
А про за фичи-то?)) А то у меня закладывается мысль, что они мне тоже нужны xD
"не читайте до обеда советских газет" и продолжайте писать хорошие статьи.
Оставлю здесь ссылку на проект с годной сборкой вима:
https://spacevim.org/
Вдруг кому-то пригодится.
Откуда такие предрассудки?))
Если есть желание, могу попробовать на своей стороне попробовать. Если подскажите по софту и что должно получиться в резльтате.
А был ли опыт работы с vi/vim? Могли бы попробовать и отписаться свои впечатления?
И похоже стучат фитнес трекеры)
Мощно! Идея не приходила в голову, но в свое время очень сильно удивился про ограничение для клиента в 1.5 гб на файл. Писал клиента telegram для backup'ов, который синхронизировал файлы из определенной директории в заданный чат.
Надеюсь что ваш проект получит дальнейшее развитие!
PS
Для помощи оформили бы issues для людей "не в теме" как помочь проекту.
А можно парочку примеров про обработку/получение событий от apiserver'а?
Давно посматриваю в сторону операторов сам. Новый подвод посмотреть в их сторону.
Какие плюсы и минусы для себя определили при работе с операторами?
Простые модели — не всегда интересно. А можно примеры сборок, да ещё и перестраиваемых?))
Ну или хотя бы примеры кода с взаимосвязями (сопряжения) тел в модели.
А в целом — этого мне не хватало лет 5 назад очень сильно.
Ну и второе спасибо деду за первые часы (sh-e 879) в доме.
вот такие
Правда я так и не разобрался, почему у меня перестали гореть лампочки, но я обязательно это починю, а пока перемычка ;)
PS
Давно хотел заняться DIY, деда меня подтолкнул к этому. Деда, надеюсь у тебя все хорошо))
Вот и приехал мой подарочек от Дедушки из Сибири! Спасибо Деда, будет чем заняться на праздниках ^_^
Весьма интересные замечания и предложения.
С этим пунктом полностью согласен, тут не будет "серебряной пули".
Не всегда сервис бывает верхнеуровневым, чтобы в нем можно было отследить данные по IP и прочее, я думаю этот кейс лучше будет решаться с помощью сквозного ID для запроса.
Наверное в случае с применением паттерна микросеврис, будет проще поддерживать активными 2 экземпляра сервисов с разным API и делать роутинг запросов на них.
Отдать должное, я в целом поддерживаю подход автора статьи, но с удовольствием посмотрел бы на другой способ применения Go kit при разработке миркосервисной архитектуры. Хотя может в случае элегантного монолита проблем описанных выше, было бы меньше.
PS
powerman если у вас есть опыт разработки микросервисов с помощью какого либо toolkit или framework, а может быть и без, могли бы им поделиться?