This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # beginners (113)
- # cljs-dev (5)
- # cljsrn (20)
- # clojure (16)
- # clojure-losangeles (1)
- # clojure-nl (1)
- # clojure-spec (17)
- # clojure-uk (5)
- # clojurescript (125)
- # core-async (4)
- # cursive (4)
- # datomic (66)
- # defnpodcast (1)
- # fulcro (25)
- # kaocha (2)
- # klipse (1)
- # nrepl (19)
- # re-frame (5)
- # reagent (3)
- # reitit (6)
- # ring-swagger (16)
- # shadow-cljs (16)
- # sql (6)
- # test-check (1)
- # tools-deps (1)
- # vim (7)
csrf-token needed when developing mobile app?
I have backend that uses csrf written in clojure i wanted to make mobile app for it and i am thinking...
do i even need csrf in this case?
backend would serve as api for authenticated users.
Am i missing something?
Hi, is that fine to have in one source set two files with the same name in different namespaces, e.g.
(ns service.grpc.api.login) and
I know it is fine from the point of the language, but I’m rather asking about good taste and best practices.
I also I’ve got an impression recently that same error logs doesn’t rely on namespaces and they operate on plain filenames. I’m not sure when I got this impression, maybe it was just me tiered and hallucinating.
@grzegorzrynkowski_clo I think it's fine but : it's common practice to alias namespaces to the last segment so both of those would typically alias to
login so you couldn't do that if you needed both namespaces in the same file -- you'd need to use distinct aliases (maybe
thanks @seancorfield, I’m using aliases in the distinct way (actually the exact way you guessed) in the Integrant system configuration. I was just curious even though we can alias a namespace whether keeping filenames unique is recommended or entirely neutral.
Hi all! I am mostly new to clojure (75% through Clojure for Brave and True, and I’ve done some euler problems) Frustratingly, I have been wanting to start a web app project for a while, but I find myself on reddit and hacker news everyday trying to find the best full stack Clojure(script) framework for beginners. I have looked at fulcro, coast, pedestal, re-frame, and a couple others, but I really struggle knowing which one is going to be the most simple to start with. I have no clojurescript experience, so preferably the “framework/lib/whatever” would be frontend and back end beginner-friendly. Anyone have recommendations for which full stack framework/lib would help me get going with minimal friction, and possibly have the best guides/docs/tutorials?
For some context, I would like the app to be able to handle user accounts, emailing users, and content uploading(photo, video, audio).
@j3elam My advice to someone still learning Clojure is to ignore ClojureScript for now, and look at building a simple HTML page-based (server-side rendering) app in Clojure to start with. You can start with just Ring, then add Compojure to handle routes in the app, then look at either Hiccup or Selmer to help you build the HTML pages. Then add other libraries as you need them.
I think it's important to learn the basics of Clojure web app development first, before trying to tackle more "complete" templates (or, heaven forbid, actual frameworks), so you understand the underlying libraries and how they work together. Otherwise, if you try to start with a template and/or framework and something goes wrong/doesn't work, you'll be hopelessly lost 😞
Clojure is not like Ruby and several other languages that prominent web frameworks that are geared to getting you up and running fast. There's no Rails here (and it's really sort of frowned on).
Once you "get" the basics, and feel comfortable building a REST API on the back end, then you can start looking at ClojureScript to build an SPA for the front end -- but those apps are very different in style and architecture to "regular" HTML apps (the sort that you'd naturally get started with in Rails etc).
@seancorfield Thanks for the thorough response! I will most likely work on a REST api for now! I happened to look into fulcro while I was waiting for a response, and it seems pretty nice, for when the time comes to tackle a SPA.
I have done the pedestal API guide, however I only understood about 50% of the code because I was a little bit lost in all of the details of intereceptors and the like. I will have to go back to the basics for now and stick to ring and hiccup I guess! I need to get routing down anyways.
If you want to look at a fairly simple but complete, working example of Ring, Compojure, Selmer, and Component https://github.com/framework-one/fw1-clj/tree/master/examples/usermanager
main.clj is a bit more complicated than necessary since it allows you to choose at startup whether to use Jetty or http-kit as the web server, but it should give you a sense overall of a possible basic structure)
Great, thanks @seancorfield I starred it to come back to tomorrow! Thanks for all of the input. I’ll let you know how the learning goes 👍
Hi everyone, I'm working my way through Clojure for the Brave and have some trouble understanding the behavior of futures.
I suspect it has something to do with laziness but can't quite wrap my head around it
I already kind of asked in #sql but in general what can you do when a program gets 'stuck', not returning from a function.
@gklijs use something like
clojure.tools/trace to figure out where it gets stuck
it will show you a lot of threads, including the JVM compiler and GC threads, but one of the threads is going to contain
that's the REPL thread. The bottom of the stack frames is
clojure.main/repl (visible as
clojure.main$repl) The top of the stack is a Reader blocked waiting on user input (that's you!)
I don't use the repl as much as I should,
gave some insights.
Does anyone have a suggestion for some design pattern to learn? Most useful for beginners?
@nathantech2005 have you watched https://www.infoq.com/presentations/Clojure-Design-Patterns
Mostly I say "Clojure/FP doesn't have design patterns -- it's just functions" but that's a bit flip and not very helpful. The reality is that it has different design patterns -- and the "classic" (OOP) Design Patterns are pretty much just functions and function composition. I was trying to find the blog/presentation that goes through the "Gang of Four" patterns and shows nearly all of them just as higher-order functions.
I hope it has some patterns because I've seen more anti-patterns in production Clojure code than I care to recount 😉
yea, I think most design patterns are not really needed in functional programming. I just want to learn some useful patterns that make code more predictable when reading code.
there are patterns like the “component” pattern, “reloadable” patterns, dependency injection, big-map-of-the-world, etc. that you see pop up in a lot of functional languages
I'm not sure how I feel about that as a practice. And I get the impression Alex has also moved away from heavy use of records these days (I think he had a bit of a change of heart after his Clojure Applied book?). Stuart Sierra's Component library -- linked at the bottom of that blog post -- is definitely a reasonable practice (and has inspired several other libraries since, but Component is still solid -- and it's what we use heavily at work).
Very interesting. Components holds the procedural steps needed to run... e.g. start db, open db, query db
Components sounds like Domain Driven Design, but instead of business logic, it is for writing concrete procedural steps that the system must follow.
Yeah, if you have a web application, there are several subsystems that need to be started up when your application begins execution: the database connection/pool, the web server, maybe your environment/configuration component, etc. The Component library lets you define start/stop "lifecycle" points for each of these, and specify what depends on what, and then it organizes the startup of everything in the right order and can shut things down in reverse.
Often in an app you only think about the startup sequence, but the Clojure way is to work based on a REPL where you want to programmatically start your system from inside the REPL and to shut it down again (you often need to stop and restart your app in the REPL if you are making code or configuration changes, although there are ways not to).
Your tests can also take advantage of this to start a minimal system for running tests and shut it down after the tests have run.
1 thing the article mentioned was mock testing... I watched a video on micro services. The person said mock testing never caught real world errors.
people do what people do. I personally do very little unit testing; mainly integration
My opinion is, they usually catch bad unit code, anyway... so start with higher level testing
i think it’s more about resource management + DI then it is about “components” in the “Component-Oriented Design” sense
I prefer a mix of unit and integration. If I would see testing as some form of proof obligation, I often use unit testing to verify my assumptions made in my integration tests
so, that means that neither my unit nor my integration tests can stand on their own
I like to ask general consensus questions. For example. Vast majority of Rails community does strict TDD
I use Rich Comment Forms a lot while I've developing -- which contain proto-tests that I run via the REPL. Some of that code becomes actual (unit) tests or property-based/generative tests along the way. I love that name for them! Stu Halloway mentioned it in one of his talks about the way Rich develops code, and I realized I'd been doing it for ages -- I just didn't have a name for it.
Yes, we use
test.check for some property-based and generative testing. We
clojure.spec in production code heavily and for some testing as well.
I find test.check immensely cool, but I usually struggle to find a way to apply it without telling my generators exactly what I am also testing
well, I did a test at work for some serialization code, that “proves” that encode/decode is identity
It would be interesting to talk about testing in a slack channel... so I can learn most popular methodoligies to use
Yeah, most of our property-based testing is around round-tripping pairs of functions. We do have a couple of more complex property-based tests where we generate sequences of valid "operations" within a system and then verify that applying those to a test system gets it into the expected state.
(or at least gets it into a valid state successfully -- i.e., the random-but-valid sequences don't hit some invalid state before the end)
right, I was hoping that I would find more ways to apply property-based testing for algorithms
it allows you to define custom generators, so by the virtue of clojure being turing complete it does 😉
You know, the text book “sort function”, that has as property that the resulted collection is sorted, without telling you how
but I end up … either not seeing these “high level” properties, or feeling like I am repeating my implementation in properties
Like you are testing too many units of code instead of just checking the final result = sorted?
@lennart.buit you mean your property tests end up looking like the functions you are trying to test?
I think property-based and generative testing scores when used on a higher-level: when you can run series of transforms or processes and then check properties of the data/system as a whole at the end.
We simply couldn't do that amount of testing manually: we use property-based testing around data migrations and certain critical interactive parts of our systems.
Those tests can create and run scenarios far faster than any human could. But it's true that you have to have an idea of what your end goal is, in order to test the property.
This is a good article about which kinds of properties to test https://fsharpforfunandprofit.com/posts/property-based-testing-2/
clojure.spec allows us to generate scenarios and sequences of operations as "programs" for input into property-based tests. Think "simulations".
Forgive me asking a lot — but don’t you have the feeling that you need to be overly specific in your generators to property test with them?
like for example in a map with dependent keys, that you need to “teach” your generator about this dependency
A lot depends on how tightly you're spec'ing things and what sort of things you're trying to generate. There's also an argument that if your data involves dependencies that make it hard to spec/generate, maybe you need to rethink your model?