Здравствуйте, Pzz, Вы писали:
Pzz>А что до вкусовщины, ее лучше за рюмочкой пива обсуждать. Я вот, например, рептилий не люблю, черепах там всяких, змей, питонов. Они еще и яйца несут, буэ.
Точно. Что жаба, что питон — отстой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
Pzz>>А что до вкусовщины, ее лучше за рюмочкой пива обсуждать. Я вот, например, рептилий не люблю, черепах там всяких, змей, питонов. Они еще и яйца несут, буэ. S>Точно. Что жаба, что питон — отстой.
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, Sheridan, Вы писали:
S>>Ну и на самом деле это камень в свой собственный огород, ибо надо не прыгать между разными версиями при разработке, а вытягивать весь код под одну версию.
Б>Речь идет про разные проекты, а не про один проект. Разные проекты используют разные версии инструментов.
Если это всё — ваши проекты, то как раз об этом я и говорю — надо вытягивать под одну версию питона всё.
Б>И это не камень в огород, а, наоборот, демонстрация гибкости инструмента.
Это не гибкость, а лень. Лень апгредить вовремя свои проекты.
Б>У меня на машине есть проекты (с гитхаба), для каждого из которых, независимо от других, настроены: Б>- своя версия питона Б>- свои версии питон-библиотек Б>- и даже свои версии системных библиотек Б>В твоем варианте ты не сможешь развернуть одновременно все эти проекты.
Я — смогу.
Здравствуйте, Sheridan, Вы писали:
S>Если это всё — ваши проекты, то как раз об этом я и говорю — надо вытягивать под одну версию питона всё. S>Это не гибкость, а лень. Лень апгредить вовремя свои проекты.
Вот клиент работает на какой-то условной версии приложения. Поймали мелкий дефект, надо быстро исправить. У тебя под этот релиз есть ветка (или тэг). Версии пакетов в релизе не самые свежие. Твои действия?
Здравствуйте, Farsight, Вы писали:
F>Вот клиент работает на какой-то условной версии приложения. Поймали мелкий дефект, надо быстро исправить. У тебя под этот релиз есть ветка (или тэг). Версии пакетов в релизе не самые свежие. Твои действия?
Разворачиваю докер с нужными версиями, чекаут нужной ветки, правлю, тестирую, коммичу, отдаю клиенту, останавливаю контейнеры.
Здравствуйте, Farsight, Вы писали:
S>>Разворачиваю докер с нужными версиями, чекаут нужной ветки, правлю, тестирую, коммичу, отдаю клиенту, останавливаю контейнеры. F>Шикарно. А то я боялся, что начнешь заодно апдейтить пакеты до последней версии.
Они уже проапгрежены в свежем релизе.
Если в проекте планируется много потоков данных, форм, таблиц. Взять например клиента для тогрового терминала.
Вроде как у рекат есть готовый набор компонент Material UI.
На этих компонентах можно свой проект построить? Или же придется все свои писать в силу нерасширяемости существующих?
Много много лет назад были в моде GWT, Primefaces. Разработчик писал Java-код и написанный код транслировался в JavaScript на стороне клиента.
Самое смешное, что тот же реакт сейчас склоняют в сторону SSR. Возврат к технологиям 10 летней давности?
В общем проблема в том, что нет исчерпывающего стандартного, расширяемого набора компонент на все случаи жизни. Или есть?
Читал статейку про сберовский Дом Клик на хабре https://habr.com/ru/company/domclick/blog/520630/
Это жесть, ребята. Выделить КОМАНДУ, которая просто занимается тем, что стандартизует разработку внутренних UI компонент, используемых в проекте.
Т.е. если раньше мы могли подтянуть библиотечку типа GWT и спокойно строить UI, то сейчас для этого надо нанимать команду разработчиков. Или все не так страшно?
Здравствуйте, Yodo, Вы писали:
Y>Т.е. если раньше мы могли подтянуть библиотечку типа GWT и спокойно строить UI, то сейчас для этого надо нанимать команду разработчиков. Или все не так страшно?
Можно просто купить подписку на готовый результат работы подобной команды:
Здравствуйте, Sheridan, Вы писали:
S>Думаю тут опять побаловаться программированием... S>Буду писать сервис+фронт к нему. S>Бакенд пока что предполагаю на питоне, а вот фронт... реакт? вуе? Или за последний год-полтора чтото новое появилось? S>Ну и было бы конечно замечательно если язык бэка и фронта был один и тот же, но не жабаскрипт (не люблю нодужс, ну вот не люблю и всё). Да и вообще бы обойтись без жаваскрипта. Пусть в него транслируется но хотелось бы писать на чом-то другом... S>Что подскажете?
1) Есть вариант elm + haskell одно семейство.
2) На последней версии жс. там вроде как классы, и следовательно типы. наверняка можно все через тайп сделать. бэков тогда куча
3) websharper (все на F#)
4) fsbolero (F# full stack)
5) clojure + script — фронт в стиле реакта, только проще, модель обявляется как атом, компоненты как функции. туллинг по vs code очень неплохой (calva + lein)
6) common lisp, так же все разметка, стили, скриты(parenscript) пишуться на лиспе. отличный хакерский подход.
7) Fable (F#) — SAFE — full stack
8) Blazor (C#)
Здравствуйте, Sheridan, Вы писали:
Pzz>>Можно написать на Go, и фронтендовскую сторону перетранслировать в JS S>Ну, go такое несколько го. Писал я на ём. Ни разу не ООП, надо подпрыгивать постоянно чтобы хоть както на ООП похоже было.
Уже лет 15 как ООП не лучший способ описать представление. Вроде как большинство библиотек реализую композицию компонентов.
Наследование лишь маленький кусочек тут. имхо.
Здравствуйте, Sheridan, Вы писали:
S>Бакенд пока что предполагаю на питоне, а вот фронт... реакт? вуе? Или за последний год-полтора чтото новое появилось? S>Ну и было бы конечно замечательно если язык бэка и фронта был один и тот же, но не жабаскрипт (не люблю нодужс, ну вот не люблю и всё).
Пиши на clojurescript, и фронт (react+cljs), и бек. Язык тот же, просветление наступит.
Eсли не готов постичь функциональщину, то питон хорош, а для фронта я бы взял typescript и angular. Angular оказался весьма неплохо масштабируемым на большое приложение (хотя в нём очень легко сделать тормозное говно, как в жаве).
Здравствуйте, Sheridan, Вы писали:
S>Думаю тут опять побаловаться программированием... S>Буду писать сервис+фронт к нему. S>Бакенд пока что предполагаю на питоне, а вот фронт... реакт? вуе?
Пиши на чем хошь, всё равно потом придешь сюда и будешь рассказывать, что фронтенды всё делают неправильно.
Здравствуйте, Sheridan, Вы писали:
F>>Вот клиент работает на какой-то условной версии приложения. Поймали мелкий дефект, надо быстро исправить. У тебя под этот релиз есть ветка (или тэг). Версии пакетов в релизе не самые свежие. Твои действия? S>Разворачиваю докер с нужными версиями
И этот человек еще совсем недавно нам доказывал что докер не нужен.
Здравствуйте, Yodo, Вы писали:
Y>Читал статейку про сберовский Дом Клик на хабре https://habr.com/ru/company/domclick/blog/520630/ Y>Это жесть, ребята. Выделить КОМАНДУ, которая просто занимается тем, что стандартизует разработку внутренних UI компонент, используемых в проекте.
И что тут жестяного? Если есть несколько крупных собственных проектов — вполне разумное решение.
Y>Т.е. если раньше мы могли подтянуть библиотечку типа GWT и спокойно строить UI,
И кто обеспечит полное единообразие UI и UX во всех проектах?
