mpenet: boorad: awesome, thanks for the input

@noisesmith: https://github.com/Lepetere/clarango

can’t say enough about the db… they seemed to have gotten transactions correct, and AQL is a good doc/graph query language

I’ve just started with emacs and cider. Out of the box expand-region seems to have no shortcut assigned. does cider use something different for structural selection?

what do people use to do authentication/authorization in clojure these days? I see friend and buddy being quite popular choices. Any personal recommendations?

@mostr: I'm just integrating buddy. I like it A LOT. Great docs. Simple api.

yeah, looks like it’s way better documented than friend is, which is kind of important to newbie

Friend seems to do more things for you—I like that it has integrated OAuth workflows, to bounce the user to Facebook/whatever for login. I just couldn't figure out how to use it for my API-request-only auth. I'm sure it's not actually hard, I just couldn't load it into my brain. Buddy, on the other hand, was a snap. Granted, I cribbed heavily from http://luminusweb.net/docs/security.md.

Hello everyone I’ve been struggling the last 2 hours to get a(ny) HugSQL statement running. I’m using Conman and Migratus to connect and configure a Postgres DB. Postgres seems to be configured correctly, since lein run migrate works. However executing any generated form from HugSQL results in an IllegalArgumentExeption with db-spec mount.core DerefableState is missing a required parameter. I have run out of ideas what that parameter might be and where to fix it. Can you guys help me out with a hint, please?

@munen - could you post the code, please?

@dm3: I have just realised that the problem only exists within lein repl and the Emacs Cider Repl. I didn’t bother to check in the web app served by lein run. Pasting all code would be too much, but I’m getting the same error when just trying the example Luminus Guestbook application. There all code is most likely properly set up and I’m still getting the same error in the REPL: https://github.com/luminus-framework/guestbook

@mostr another +1 for buddy

munen: that error is very much like the one clojure.java.jdbc throws is you pass the wrong thing in for it's "db spec" parameter, where 'mount.core' seems like the wrong thing being passed in, are you passing a symbol in to java.jdbc somewhere?

you should pastebin your stacktrace

Why does assoc-in not support more than 3 args similar to assoc?

@john.care: cider uses paredit for structural stuff

@hiredman: I’m leaving the facilitation of the actual connection to Conman which in turn refers to mount.core. I’m not directly communicating with jdbc.2 My Code looks very similar to this: https://github.com/luminus-framework/conman#defining-queries

munen: very similar doesn't count for much, you should pastebin the stackstrace

@hiredman: Interesting enough, I have realised by now that the actual code works fine when run in lein run. It’s just lein repl and Cider Emacs that do not work. Which is kind of unfortunate.

@hiredman: Since it works in lein run, I think it’s probably less about the code then some environmental issues. But I’d gladly pastebin the stacktrace. Mom.

Mom?

One moment(;

http://pastebin.com/ZBXWpBTs

This is the trace I’m getting for all HugSQL forms. My guess is that it wants an explicit connection passed in.

it looks like slack ate part of the exception message you shared earlier

`db-spec [email protected] is missing a required parameter``

@martinklepsch: there's a ticket for that http://dev.clojure.org/jira/browse/CLJ-1771

some an instance of mounte.core.DererableState is being passed in to clojure.java.jdbc as a db-spec

@alexmiller: neat, should've checked

mount is a sort of component like system, right? so mount.core.DerefableState must a component, so somewhere you have a component that contains a db-spec, and instead of pulling the db-spec out and passing to the database code (hugsql or java.jdbc) you are passing the component in

Do any of you know how, or is it not possible in clojure by design, to expand a symbol to a function name? Example: (defmacro x [func & args] (pkg/@func @args))`

oops… formatting. 😛

Oh, maybe it’s a symbol vs. value issue.

hiredman: Thank you for your help! You are certainly right in that the wrong thing is passed in. However, I do not get why there should be anything passed in at all. I’ve been stuck for 6 hours without fix and it’s getting late. I’ll try some sleep before getting back to it. The help is much appreciated!

munen line 30 of issue_tracker/db/core.clj

hiredman: Oh my, I have a solution! If I manually execute (mount/start #'issue-tracker.db.core/*db*), then I can start HugSQL queries like (db/get-user {:id "1”}). Still.. I can find no mention of this need in the docs. You brought me on the right track for a manual solution, though. That’s good enough for now. It’s much appreciated, thanks!

@clintm: you probably want 'resolve'

@munen: take a look at (try) the mounted luminus guestbook branch: https://github.com/luminus-framework/guestbook/tree/mounted it should work without you manually starting db, it should make it to the release/master soon

@munen Someone had a similar issue here: https://forums.pragprog.com/forums/387/topics/14104

I just don't understand why people use mount, I must be missing something, its model of each namespace as a component, with state as a global thing in a namespace(maybe I am mistunderstanding this), just seems bad, like sticking (def state (atom {})) in every namespace would be

https://github.com/tolitius/mount/blob/master/src/mount/core.cljc#L10-L14

@hiredman: could you elaborate on the actual problem you see there?

note that mount doesn't tie the functions in your namespace to the state in any way

you can still use a protocol with it if you like

all it does is track the lifecycle of stateful variables

global state variables, right?

you can only have a single instance of these state variables per clojure runtime, and it is visible to any and all clojure code, right?

yes, what is the problem with that

if I have a database, I necessarily have a single instance of that database

but that isn't a database

this goes for pretty much any external resource

that is a connection to a database

sure

and there's still precisely one connection per database

and there are plenty of reasons you might want more than one connection to what ends up being the same database

could you name one

I see no reason why you wouldn't want to centralize code that accesses an external resource

you structure your app in such a way as to have to logically distinct databases, eahc having their own "connection" but in production your ops team decides to use one database

I've seen that happen multiple times

and how is this at odds with mount?

you create a defstate per connection instance

and it manages that connection instance

either you have one connection defined in your app, or you have multiple

if you want to test running a cluster of your server, if you don't use global state you can run multiple copies in the same jvm, with global state you cannot

you would have to explicitly write your app to use multiple connections

why would you need to run tests on the same jvm

is there a repl shortage that we're experiencing?

this is the only argument I've ever heard against the mount approach

writing a deftest that runs multiple jvms is way more involved

that's not what I meant

I am kind of surprised, are you seriously argueing that global state in an app is a good thing?

I meant that you should use lein profiles to specify a separate configuration for your test profile

the actual code in the application should be environment agnostic

like you have no problem with code that does (def foo (atom {})) everywhere?

you still haven't provided a concrete example of a problem

so if you have a problem with the mount approach, then could you please articulate it

the problem with global state is generally that it ends up being being difficult to track in the application

however, this is not what happens when you use mount

it is hard to articulate an objection to something that I think flies in the face of functional programming since the invention of lexical scope

if something is global, it isn't scaoped

scoped

so basically you're saying that you dislike it for dogmatic reasons

it cannot be local, you cannot have your own copy

passing your state around in a global var that's referenced everywhere as you do with component isn't any different conceptually

no, I mean, I have used and worked on systems that didn't have a way for different parts to keep state outside of (def foo (atom {})) and it was terrible

in fact I've seen it make things far more problematic, because now your entire app depends on the state being available

writing large test suites, ok, which bits of global state where need to be written and set up for this test

but majority of your application should be stateless by design

the whole point of using a functional language is that you only deal with state at the edges of your application

mount allows you to represent stateful resources and provide an API for them

but those are predominantly dealing with IO, and have no actual business logic in them

with mount, you don't need your external resources for testing vast majority of the time

yet, I've seen many component based applications where state was passed around all over the place as the system map

and none of the application could be tested without external resources being available

at my last job, our largest codebase, predated component, mount, whatever, and it was largely written as just a bunch of namespaces, and if they needed state the had to use some kind of global mutable thing. whenever the opportunity for a new project came up, no one chose to do that again

sure, nothing guarantees automatic correctness

right

you still have to be mindful of your design whatever approach you take

and just because you saw a mess with global vars, doesn't mean global vars were the inherent problem

same as if I saw a mess made with component, it's not necessarily component that's at fault

however, if you understand why global state should be isolated then you can do that equally easily with both monut and component

and neither is a substitute for that understanding

If I can’t run multiple instances of my system in the same jvm, I think that’s a design problem

I have yet to see a practical use case for that

this pattern seems to be specific to the reloaded workflow

I am not saying global vars are a problem, clojure vars are global, I am saying a global atom is bad

I have never used the reloaded workflow

my experience is that having a namespace that represents the resource is a very clean way to isolate stateful components

but I have definitely written tests, where I wanted to observe how multiple instances of a server interacted together

and I still think it's much cleaner to run each instance in its own jvm

but that's the tradeoff you make

both options are available

however, you said that you don't understand why people use mount, and I'm explaining my rationale for using it

there are trade offs right, depending on whatever, running each an its own jvm may be cleaner, but is that fast enough to run as part of your regular test run, how painful is it to maintain the clojure.test code to do that

I find that I don't need to access resource for majority my tests

because I structure my apps to be predominantly resource agnostic

in most cases I'm testing the business logic

I'm not testing my database or the database connection

yogthos: yeah, I am just kind of shocked, like if I saw code in a code review that had (def foo (atom {})) in it, I would require a lot of explaining

mount seems no different, and it is getting built in to stuff

in fact I would argue that if you need access to resource to run mosts tests, that's a problem with the deisgn

I think the conceptual model for mount is very simple

you have a resource and you have an API for accessing it

to me it makes perfect sense to use a namespace to abstract that

furthermore this helps provide real abstractions over the resource

what if its nature changes

I might be using a database today, and switch to using a service tomorrow

the rest of the application shouldn't be aware of the details of where the data comes from

right, that is exactly the argument for lexical scope

direct passing of parameters, etc

I don't see how that's the case

if you pass parameters from your business logic, you've coupled your business logic to the resource

that's a bad thing

I need an A, I don't know where A is, someone just passes me one

and if fact the person that passes me an A, maybe have 100 different As to choose from, or may just create and destroy one on the spot

I'd much rather have a shallow layer that deals with IO that sits around the core business logic that's resource agnostic

again, you have to actively structure your application to isolate stateful code

period

and mount doesn't make it any more difficult

sure, but code that takes parameters is by definition less coupled than code that doesn't

the only limitation is that you can't run multiple instances inside the same jvm, if that's a requirement then mount is a bad fit, if it's not then it's perfectly fine

I've been working with Clojure for about 6 years now, and I haven't seen that be a requirement yet however

right and in my case business logic takes data as a paremeter

it is inherently decoupled from the resources

@hiredman, @donaldball: > if you want to test running a cluster of your server.. > if I can’t run multiple instances of my system in the same jvm, I think that’s a design problem > it cannot be local, you cannot have your own copy.. in those rare cases (the only one I know of is "running tests in the same dev REPL") you *can*: https://github.com/tolitius/yurt but learning how people use mount, I see that there is no shortage of REPLs in that one use case. besides, running something like boot watch speak test in another REPL is great regardless of whether you using mount or whatever

but isn't this just piling complexity (managing multiple clojure runtimes) on as a bandaid to a problem you wouldn't have to start with, with out global state?

ding ding ding

I like it when arguments are provided (outside in), not discovered (inside reaching out)

it's a problem most people don't have though

you have the argument anyways, whether you see it or not

the db is an argument to a subsystem that accesses the db

I see the db as a separate component from my business logic

my view is that you should be able to take the business logic and package it as a library

i think that's optimistic in a lot of cases

if you can't then your system is coupled

I haven't found this to be problematic myself

i have

¯\(ツ)/¯

and that's why we have different people using different things

yeah

https://gist.github.com/hiredman/27733 is the earliest clojure code of mine I could find, from 7 years ago, anything earlier is likely lost to lisppaste

there isn't one true way to write applications

that's a slippery slope fallacy though

I will make another fallacy --

I don't think anybody will argue that you can't make a mess with mutable state

of course you can

saying that because you can make a mess all state is bad is a stretch

and I don't see how coupling your business logic to your resources makes the problem any better

I've lived a war story of trying to remove Korma (sql) from a system over a year or so... I'm afraid mount will lead to similar situations, because the root cause (ambient global state) is the same

you still have global state for all intents and purposes, and now you can't even test anything without it

yogthos: you have been argueing against coupling business logic to resources, but no one was said you should

yet that's what I commonly see with component

and not just component in fact

if you look at other DI approaches, this is quite common

you have a singleton that gets passed around all over the app

but that is a false dichotomy, right?

just because you see it in component, doesn't mean you don't see it in mount

so is saying that mount = (atom {})

yet you've made that analogy a couple of times here

yogthos: false equivalence

(is I think what you mean there)

is defstate global mutable state?

hint: defstate

of course it is

does it mean that it will make your app into a giant mess magically

of course not

in fact

if you use monut or component, you're going to have to structure your app in a very similar way to avoid this problem

Huh, that’s not been my experience with component either. The various fns that require (probably protocol implementing) arguments get them explicitly, not the whole system blob.

but where do they get them from?

they have to be passed in from somewhere

since you're not keeping any global state, you have to pass it around

so now parts of the application that shouldn't care about the state have to take it as a parameter

that is just not correct

yeah that isn't

ok...

In my case, a ring handler component got refs to the components needed by the various app handlers and injected them into the requests

right

when you create a component system, you tell it about the dependencies between components, and each component only has access to the bits you say it needs

yeah your system has to be accessible though

no it doesn't

to the individual components? no it doesn't

parts of it do

lots of people make the system accessible as part of the "reloaded" workflow, but it absolutely is not that way in a prod deployment

look, your app initializes, it creates the system then resources in that system have to become available to functions that use them

there is no way around that

now you can either keep that interaction at the edges of your app

yogthos: right, and the way that happens is, you explicitly tell component when creating the system, which components need each other

or not

it's same with mount and component

components reaching their grubby little hands to find some piece of shared state that they didn't tell you that they needed initially is the problem

that's not the problem I'm talking about

I'm saying that if you have a piece of business logic and it has to accept any stateful variable as a parameter because it calls a function that uses it then you've got coupling

I'm also saying that plenty of systems using component do precisely that in the wild

and I would go as far as to say that component encourages this approach by design

I want some sort of limits/bounds on the parameters to a subsystem. I hate having to use something that has interactions beyond where it should

Having explicit arguments helps with ^

in fact examples of that can even be seen in presentations on component

people are so frigging lazy

if you have a piece of busines logic that has to use some state, but you reading it from a global place instead of passing it in, you've got even more coupling

i don't want the DB parameter passed around

@hiredman: my whole point is that business logic should never need state

-- said people who were bitten later

pretty much by definition I would say

you should always be able to deal with external resources at the edges

and if you aren't then I'd say that's a problem

business logic should operate on the data

i can get behind that as a generalization

I'm a little surprised that this is controversial somehow

specifically, mount doesn't support you in realizing that

so if we agree that business logic should be state agnostic

mount doesn't only support it, it encourages this

let's write code

ok

let's write code

what would be a simple example?

let's say we have a service operation to authenticate a user

the user comes from the database

ok

we accept a request, get user info, authenticate

I would treat authentication as the business logic

while the code that talks to the client and the database would be the IO layer

does that sound like a reasonable distinction?

seems reasonable, but it depends on where exactly that line is drawn

say more about authentication?

so with mount I might write code like this

parts that care about the state are the POST handler and the db

k i don't like that right away =(

that's fine

I do though

and that's what counts to me

Fair enough 😉 I was thinking authentication should know nothing about where it comes from

only parts that care about IO are the POST route and the database namespace

once I got the data, that gets passed to the core of the app

and the core of the application doesn't care one bit where it came from or where it goes

(defprotocol IAuthenticator (authenticate [_ user]))

it doesn't

it knows it comes from the db

all it knows is that it got a map

not from an LDAP service

no it doesn't

I pass the user value to the authenticate method

ok, which part is the map?

user

that's the map returned from the database

ok

by the db/get-user method

the database API is effectively getters and setters

there's no logic

the POST handler also doesn't have any logic

this is the layer I'm talking about

alright

you can think of it as serialization/deserialization of data from external resources

how do you test this?

I can test authenticate by passing it a mock user record

I don't need any access to resources to do that

I can do end to end tests by providing a test resource

but I would do that very rarely

is authenticate a pure function?

I tend to run full tests before I commit code and on the build server

yes

absolutely

it takes data and it returns data

it's not aware of any state or resources

you can test authenticate, how do you test the whole route?

it's not so obvious

the route would require a test resource for testing

in the db?

I would test it in a separate repl with a test profile

right

but as I pointed out already, my experience is that I need to do this kind of testing rarely

where are your pure functions now

precisely because I don't keep business logic in the layer that deals with the IO

in my business logic

the thing that's the lions share of the application

if you want to vary multiple implementations of components together -- I've found component to be very useful. Sometimes the components have to be a level up from typical logic (e.g. UserStore vs Database)

sure

so how is this at odds with mount?

you can create a protocol say for a queue

then initialize instances of the protocol each with its own state

different vars?

of course

if I have two different queues, they're conceptually two separate resources are they not?

by their very definition

oh I meant different implementations of the same resource

sorry confusing

not separate resources

what is an example of that

Like LDAPUserStore vs DBUserStore

you'd write two separate implementations of that wouldn't you

each would be a separate namespace

yes -- how do I instruct the subsystem that consumes a UserStore as to which one it should use?

I would be explicit about that

binding vars?

you're not going to be randomly switching between what store you use

right

so then can you give a concrete scenario

test vs normal

then I'd provide a different resource in the profile

but why would I test against two completely different types of resoruces?

that seems like a recipe for disaster to me

if my app goes to ldap in production, I would surely want to use the same mock api in tests

sometimes it's the same impl, but a variant. For example, fault injection

let's put it this way, your worst case scenario with mount would be your best case scenario with component

you test that a slow network is handled properly with timeouts

you'd create a protocol and a record that wraps whatever states you want

you'd still retain the same api for the resource in that case

mock resources should have same api as the real resources

but you have to know which internal resource to mock in that case

if I had a mock connection in my defstate then it should behave like a real one right?

how so?

what's an internal resource by the way?

you have to know how a subsystem works intimately, to be able to mock it effectively (with mount)

that problem is gone by design with component

I disagree

which is an important distinction

in fact sounds like you're setting yourself up for a bigger problem

since you don't know how your system works, you can end up with bugs around the edge cases

I certainly wouldn't advocate such an approach

if you have a mock of a resource that doesn't exactly match how the real one works, that's extremely problematic in my opinion

the ability to cleanly interchange means you've designed good interface

but what does that have to do with mount?

if I have a database connection managed by deftate

its interface is the API that I implement

that's the resource

reaching for resources rather than taking your arguments

I think we're going in circles here

we already covered this point earlier, with examples to boot

if you prefer the way component works, it's there and nobody is asking you not to use it

but there's absolutely nothing wrong with using mount either

it's a personal preference, and different people like different things

but I have yet to see a coherent argument against using mount

It's clear we disagree (still), but I'm happy to have had the discussion!

same here

I don't think it's wrong to disagree, a lot of things come down to tradeoffs, and different apps have different needs

there's no silver bullet for this

having options is a good thing in my opinion

I find that people tend to have different preferences based on their experiences and the way they like to approach problems, and it's always good to have these kinds of discussions to get a broader view of things