This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-20
Channels
- # aleph (19)
- # aws-lambda (8)
- # bangalore-clj (1)
- # beginners (13)
- # boot (179)
- # cljs-dev (12)
- # cljsjs (2)
- # cljsrn (6)
- # clojure (174)
- # clojure-italy (14)
- # clojure-nl (2)
- # clojure-russia (172)
- # clojure-spec (29)
- # clojure-uk (22)
- # clojurebridge (10)
- # clojureremote (1)
- # clojurescript (79)
- # cursive (46)
- # data-science (1)
- # datascript (8)
- # datomic (18)
- # defnpodcast (2)
- # emacs (9)
- # events (6)
- # hoplon (11)
- # klipse (13)
- # lein-figwheel (1)
- # leiningen (1)
- # luminus (1)
- # lumo (88)
- # numerical-computing (1)
- # off-topic (24)
- # om (33)
- # onyx (58)
- # protorepl (8)
- # re-frame (10)
- # reagent (26)
- # ring (8)
- # ring-swagger (7)
- # rum (22)
- # spacemacs (25)
- # specter (5)
- # uncomplicate (37)
- # untangled (75)
- # vim (17)
- # yada (3)
А есть какая-нибудь либа типа, (minify-html-js-css (response page))
чтобы страницу ужать?
gzip?
gzip включен и так, надо что-нибудь типа такого http://kangax.github.io/html-minifier/
@troglotit за ядро кложи - спасибо. На счет боевого ML. Боевой ML это не столько код в продакшене, сколько тьма экспериментов, проверок гипотез и всего прочего. И далеко не факт что результат будет успешным и уйдет в продакшн. Зачастую бывает что нет. Только когда уже станет ясно, что эксперемент норм, качество растет, roc auc повысился, тогда уже модель можно вкручивать в прод. А потом продолжать ее дорабатывать. И тут менять язык и реализацию немного неудобно т.к. получается двойная работа которую никто не оплатит. Это когда станет понятно, что с модель уже никак не улучшить, а ее качества достаточно для бизнеса, тогда да, можно переделывать на скалку. А с драйверами к кафкам и онлайн обучением у питона тоже все нормально: пользуемся. На счет деплоя питонячих ноутбуков: можно да, руками переносить, если не лениво. Можно в ноутах писать сразу production ready код и встроенным макросом сохранять его в файл (привет, литературное программирование). Можно даже запускать ноутбуки как микросервисы (: Тут есть варианты.
@dottedmag Заюзал https://github.com/serg472/htmlcompressor с Closure Compiler-ом, а зачем в hiccup?
@kxepal вот уже машинки готовые раздают на AWS с TensorFlow, питоном, CUDA и Jupyter из коробки…
@ilevd Затем, что CC умеет минифицировать джаваскрипт, а минифицировать HTML он не умеет.
@potapenko круто, но у нас своя инфра для ML (:
Господа, а расскажите, кто как готовит CSS и картинки? Closure Compiler - это круто, но только для HTML ведь.
@dottedmag я предложу, наверное, не очень популярное решение, но тем не менее. ИМХО нужно делать нечто на тех технологиях, которые для этого предназанчены. Писать фронтенд на clojure можно, но бессмыссленно. ClojureScript по определению вторичен и не может успеть за js. Невозможно найти верстальщика, который будет верстать в css data dsl. Под фронтендом я тут подразумеваю верстку и логику отображения. Итого весь фронтенд можно писать на изначальных веб технологиях вроде react, postcss, ES6+ и собирать все это с помощью webpack. Webpack так же умеет встраивать картинки в сss через base64. Webpack выдает один js файл с включенным в него css. Этот файлик удобно подключать в clojurescript проект. На clojurescript пишется сама бизнес логика, использующая фронтенд. Из кложи удобно работать с компонентами реакта через реагент. Если интересно, я могу показать примеры.
https://github.com/darkleaf/quester я еще не закончил фичу, но вот интеграция js сборки в clojure https://github.com/darkleaf/quester/pull/56/files#diff-e9d92ef27ccb32d86196f716e23e8f4eR8
чтобы не было проблем при optimization level advanced пришлось извернуться https://github.com/darkleaf/quester/pull/56/files#diff-99d49414962939ea6e02660c6fb059adR32
https://github.com/darkleaf/quester/pull/56/files#diff-243f3231995a4dd6a1e63ef144d61ef8R7
используется это например так: https://github.com/darkleaf/quester/blob/master/src/cljs/quester/components/pages/main.cljs
@fatwebdev задавайте вопросы или тут или в личку
@kuzmin_m я правильно понял что ты предлагаешь компоненты которые используют стили писать в js и потом их дергать из cljs?
мне кажется тут больше проблема что ClosureCompiler не работает как webpack и все
так вот, BusinessItem содержит код на кложе, и получается, что PresentGallery знает про кложу а такого быть не должно в этом случае все просто, BusinessItem предается как this.props.children но бывают случаи сложнее и как решение - использование DependencyInjection компоненты получают свои зависимости чреез props в cljs коде есть самописный DI container
> мне кажется тут больше проблема что ClosureCompiler не работает как webpack и все clojurescript вторична она не может успеть за всем
так children и есть prop
че то я не понимаю, какие то сложности ради того чтобы css-modules юзать
https://github.com/darkleaf/quester/blob/master/src/ui/examples/main-page-example.jsx#L212-L218
по моему все просто, пиши css в cljs и не парься
нафиг нужно такое нагромождать
верстальщик так же не будет тебе react компоненты писать
проходили, знаем
кстати, те же модули можно без webpack делать на выходе будет json с преобразованием классов “class_name”: “SomeHash"
>Писать фронтенд на clojure можно, но бессмыссленно. ClojureScript по определению вторичен и не может успеть за js. ИМХО конечно, но по мне так это JS догонять ClojureScript еще лет 5 нужно.
собственно бизнес логику здорово писать на clojurescript например очень полезно шарить код
что мешает компонентами для реакта пользоваться из клжс? (https://github.com/little-arhat/llexus-form например)
npm зачем нужен? https://cljsjs.github.io/
во фронтенд разработке не могут определится как писать ) ооп или функциональщину, какой стандарт
я выше описал подход когда фронтенд делается на изначальных технологиях а логика пишется на cljs причем фронтенд может независимо разрабатываться так же есть разные команды, с разными ресурсами и потребностями кому-то этот подход может показаться интересным кому-то нет я занимаюсь этим проектом около полугода и не могу в 2х словах объяснить все проблемы и решения к которым я пришел
> куча готовых компонентов для реакта и все что с ними можно сделать это выкинуть и забыть
в целом, у меня совершенно противоположное мнение, это у жс инфраструктура уже сейчас на столько отстала от клжс, что и не догонит никогда, смысла писать на жс, а не на клжс вообще не вижу никакого (кроме отдельных узких случаев), особенно сложные UI-программы
из всего вышеперечисленного только webpack имеет какую то ценность, но при этом оно такое большое и такое говно и так активно переписывается boot-сообществом, что скоро тоже не будет актуально
я не думаю, что проектов много на клжс, на жс проекты тоже вроде не каждый выкладывает вроде?
@prepor А какие отдельные узкие случаи, кстати? Я так прикидывал, что даже скрипты для эмбеддинга на веб-страницы, где размер важен, вполне себе компилятором ужимаются до приличного вида.
120кб для хелло ворлда все же не для всех "приличный вид", так вроде было когда я мерял
Да ну, у меня до 2 кб ужималось. Как-то раз в cljs регрессия была, что hello world тащил за собой кучу кода.
в общем в любой маломальски умеющей что-то клжс аппе будет несколько десятков тысяч строк рантайма
Ничего не приходит в голову, кроме как опять же скриптов для client-side analytics.
во-первых, для браузера вариантов все равно нет, во-вторых, мало ЯП таких же шустрых как современный жс
Господа, а как бы покрасивее написать
(fn [s] (or (not (contains? s :selection))
(< (:selection s) (count (:matching s)))))
?Т.е. если :selection
в карте, то он должен быть меньше количества item'ов в :matching
@prepor Попробовал бы ты рассказать об этом стандартному жс деву. Я могу быть неправ, но мне кажется на жс много гонят от незнания всего, что там происходит. Хотя и со многим я согласен.
@kuzmin_m на cljs примеры проектов? https://precursorapp.com
это для дизайнеров
@dottedmag (defn x [s] (boolean (when-let [sel (:selection s)] (< sel (-> s :matching count)))))
?
@dottedmag не, boolean же