This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # architecture (18)
- # aws (7)
- # babashka (63)
- # beginners (39)
- # bristol-clojurians (1)
- # circleci (1)
- # clj-kondo (10)
- # clojars (4)
- # clojure (159)
- # clojure-berlin (3)
- # clojure-europe (4)
- # clojure-italy (7)
- # clojure-losangeles (6)
- # clojure-nl (7)
- # clojure-spec (3)
- # clojure-uk (109)
- # clojurescript (54)
- # crux (13)
- # css (1)
- # cursive (38)
- # data-science (2)
- # datascript (3)
- # datomic (14)
- # docker (2)
- # duct (11)
- # fulcro (47)
- # jobs (8)
- # jobs-discuss (3)
- # kaocha (4)
- # malli (3)
- # nyc (2)
- # off-topic (30)
- # overtone (3)
- # re-frame (17)
- # reagent (33)
- # shadow-cljs (29)
- # spacemacs (3)
- # specter (4)
- # tools-deps (13)
ClojureBridge coach training this evening in London at Signal AI (near Old St. roundabout). We are looking for another 4 coaches to help with the event to match the 20 students we are aiming for. https://clojurebridgelondon.github.io/ Coaching is great experience for your career and at ClojureBridge London it will help you understand how much Clojure you know and if you have any gaps. You are also helping someone else get into the software industry at the same time. If you would like to coach but cant make it tonight, please get in touch directly (direct message me here). Thank you.
I want to deploy an authenticated repl for my service. What are people doing to deploy this securely ssh reverse proxy + normal repl listening on loopback? Is there a better way wrapping the connection in TLS or something?
i tend to use ssh proxying as the default for most secure admin access - it seems hard to improve upon a single pubkey-only openssh port being the only admin route into your cluster
Anyone got a good recommendation for an up to date Clojure / Clojurescript Template (for
lein new or
clj -A:new) for a small website, i.e. limited overall size / amount of content and no Clojurescript complicated enough to make Reframe a requirement, Reagent will cut it..?
@maleghast: a minimal one would probably just be to do this: https://github.com/thheller/shadow-cljs#quick-start
Thanks - I may have to fork that one and write my own as I want a bunch of back-end stuff as well, but this (shadow-cljs#quickstart) looks like a good place to start, thanks 🙂
(Clearly if anyone knows of a template that does both, preferably with Yada and Bidi, 'cos I know them, then that will save me the time of putting one together 😉 )
Your requirements (or lack of them) suggests just using the app template and adding the libraries you want.
@ - guess which page on Github I have open this morning after a lot of thinking and reading..?
@ - Yes, I could do that, but as I explained to @guy in a thread yesterday I do have my reasons for wanting to roll-my-own
@ - I will.... I think that I am still going to put together my own template at some point, but for now Edge still wins.
If there's something about edge that could be different better, I'd certainly be open to hearing it!
@maleghast I would only recommend using shadow-cljs if you have specific npm packages you want to use. Also be aware that some parts of shadow-cljs are undergoing a significant rewrite. The project also failed to download last week.
For templates, If you just want a front end, then figwheel-main +reagent is the simplest react style. If you want full stack then luminous template. Or just use app template and add libraries when you actually need them.
Oh, it seems counter-terrorism is now illegal in the UK. So happy time for all the billions of terrorist in the UK https://twitter.com/MrMichaelSpicer/status/1224619601738137600?s=19
i've found shadow to invaluable on a larger cljs project, but it's easy enough to switch to it later, so no particular reason not to go with the easiest thing at the beginning
I think there’s a small bug though; which initially confused me which is that shadow doesn’t seem to source
user.clj, so you may manually need to load your dev namespace manually first
I think I didn't want that file at all. I'll have to check. I wanted it in my config.edn where I had aero
I need to look into whether that has changed yet, but I didn't get the impression it would.
OK, that escalated quickly - I just did the school run and suddenly the World is on its head again.
having more core.async fun - one thing I really liked was being able to take a slow (wall clock) mapping function and push it through a pipeline and cut 1/3-1/2 off the total execution time of my processing pipeline
without having to worry about spawning loads more threads (tho I do need to be careful about how much of the pool I'm using if I use the pool threads)
early days, but I was pretty happy that I was just able to slap a
(pipeline 3... in the middle of my flow
@otfrom we have a
map-concurrently fn for manifold streams which lets you do similar things
@mccraigmccraig cool. I'm guessing that lets you dial in the level of parallelism you want?
all it really does behind the scenes is use a buffered stream to control the number of realized mapped values in existence at any point in time
What's the feeling? Do people intentionally mark their functions private (either with meta data or with
-) or don't care?
Yeah if its owned by you and only your teams gonna see it, i would just whatever everyone likes the most
@dharrigan I feel that it is a good, if wanky and philosophical, exercise to try to make every function independently useful.
I don't really use private functions any more for this reason. A part of my brain now considers it a failure of design 🙂
This is not to say that you necessarily should use them outside of the namespace they are in, just that they are isolated and independent units of functionality.
I've gone back and forth on this. I've found that if you use a linter like Joker in real time in your editor, having
defn- for implementation functions is very useful when you're refactoring since unused functions get highlighted immediately. But I like being able to easily test (some) of those functions and sometimes they become useful to other namespaces.
So my baseline tends to be: in a library, make everything public by default, organize by namespaces to indicate "implementation" details and either use
^:no-doc or explicit wording in the docstring to discourage use of functions you do not consider part of the API. But in application code, use private by default and make things public as needed over time (and pretty much only ever test public functions still).
After nearly nine years of production Clojure work -- on the same code base where I was pretty much brand new to Clojure at the start of that -- there are parts of our code base that I hate and several decisions we made "back in the day" that I have been actively reversing over the last year or two. Huge amounts of painful refactoring.
One of the most painful decisions we made early on was to allow a certain amount of global state "hidden" in a few namespaces, rather than pass those things through the call chain. That has made testing much harder as functionality has increased/changes and it has made some new functionality extremely hard to implement. In particular, we had some global data source vars that we regret hugely, and some dynamic and/or inheritable thread local vars that were also a huge mistake.
Well, was up early, so refactored my code to remove all state that is stored in a namespace as atoms. Now, any state, like a connection pool is stored in a map that is passed around to functions that need a db connection
From this, and from other chats, in my application, I've reduced down to nearly zero (just a bit of refactoring to get to zero) any global state. Anything that is part of the system, is passed along as a parameter map to functions that need it.
so when writing tests, I can easily craft a parameter map with "dummy" things to exercise code paths and functions
Yup. Never assume you'll have just one database connection as your app grows. We started that way and now we have five I think.
We have two readonly connections: one has access to only one schema, one has access to all schemas. Plus we have dedicated connections for each schema, with write access.
@dharrigan LMK if you have any Qs about
core.cache. Are you using the
wrapper namespace to handle the atoms for you?