This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-04
Channels
- # architecture (20)
- # aws (8)
- # beginners (13)
- # boot (9)
- # cider (80)
- # cljs-dev (69)
- # cljsrn (7)
- # clojure (243)
- # clojure-dusseldorf (8)
- # clojure-italy (5)
- # clojure-norway (3)
- # clojure-poland (57)
- # clojure-russia (10)
- # clojure-shanghai (2)
- # clojure-spec (11)
- # clojure-uk (50)
- # clojurescript (198)
- # core-async (11)
- # crypto (2)
- # cursive (14)
- # datomic (17)
- # figwheel (8)
- # garden (7)
- # hoplon (8)
- # incanter (4)
- # jobs (1)
- # leiningen (1)
- # liberator (38)
- # lumo (28)
- # om (55)
- # onyx (10)
- # pedestal (13)
- # perun (20)
- # re-frame (1)
- # reagent (16)
- # ring-swagger (9)
- # spacemacs (11)
- # test-check (9)
- # unrepl (43)
- # untangled (163)
- # yada (8)
Nie ma szans z Clojure AFAIK. Popularne języki - jak najbardziej, firmy przyjmą samouka bez doświadczenia komercyjnego, tylko trzeba zaprezentować, że się coś umie (otestowane projekty).
Zagraniczne firmy szukają kontraktorów z clojure/cljs.
Jestem starym kucem z brodą, ale tak mi się życie po układało, że dopiero teraz będę miał możliwość się przebranżowić i robić zawodowo to co zawsze robiłem do szuflady
Bycie samoukiem to nie problem — ważne, żeby coś umieć. @not-raspberry słusznie mówi. Najlepiej pokazywać gotowe, samodzielnie stworzone projekty na githubie.
I tam „w mainstreamowych językach”. Język jest sprawą wtórną. Albo ktoś umie, albo nie — przy pracy z prostymi językami szybciej wychodzi czy umie 🙂
U nas w Retailic na przykład (w zasadzie wszystko od lat piszemy w Clojure i ClojureScript) jest istotne nie tyle komercyjne doświadczenie co pokazanie, że potrafi się budować oprogramowanie. Jak mówiłem, dobre projekty na Githubie. Najlepiej w Clojure + ClojureScript, bo u nas używa się jednego i drugiego. Można napisać coś, CRM, czy inny CMS, używając React+Rum i będzie dobry punkt startowy do rozmowy.
A co do „ludzi na drugim roku biorą by tylko umieli trafiać w klawiaturę” — to tak może robią firmy, które nie przejmują się jakością tego co dostarczają. My się przejmujemy. Nie wystarczy trafiać w klawiaturę. Ale to wszystko jest niezależne od języka.
huxley: luminus z postgresem i reagentem
W przyszłości luminus z re-framem (czyli w sumie też z reagentem).
Luminus to w domyśle ring z sensownym middlewarem, undertow jako serwer, hugsql do bazy danych.
Migratus do migracji
Component do komponentów
Wszystko z http://juxt.pro jest dobre
Skoro mam sobie ułożyć ścieżkę "od zera do Clojure developera", to każda wskazówka cenna ; )
A różnie, co ma sens. Datomic raczej nie, datascript czasem, mount albo component (warto poznać oba). Ze stałych rzeczy to jest React (poprzez rum) i sente. Serwer ma małe znaczenie, ważne że ring.
Ale tak serio, nie wolno być ani "programistą PHP", ani "programistą Clojure+Datomic+Component+Aleph". Takie rzeczy się zmieniają i często wybory nie są oczywiste. Trzeba się uczyć wszystkiego, nie poprzestając na rzeczach prostszych.
Rum jest najbardziej elastyczny i najmniejszy. Pozwala na mieszanie różnych stylów w zależności od potrzeb, nie narzucając żadnego modelu odgórnie. To bardzo praktyczne.
om.next rozwiązuje dodatkowo drugi problem — skąd i jak wziąć dane do części klienckiej aplikacji. Jeśli się tego potrzebuje i tamto rozwiązanie jest OK, to też warto rozważyć. A zacząć najlepiej od Reagent, bo jest najprostszy (ale też szybko ogranicza).
No i super 🙂 Mamy w świecie ClojureScript ten komfort, że wszystkie biblioteki do React są naprawdę niezłe.
za czas jakiś, pewnie dłuższy niż krótszy, nie zdziw się jak dostaniesz CV wraz z linkiem do githuba ; )
właśnie przypadkiem odkryłem, że https://www.frisco.pl/ jest napisane w rumie