Am I missing something?

2013-12-03 Thread James Laver 
Hi all,

I'm fairly new to clojure (a few months), but not new to lisp or indeed 
functional languages in general and I have around 10 years of experience 
programming dynamic languages in general.

I've recently been using luminus to build a RESTful web API and I've been 
honestly surprised by how much code I've had to write to enable me to 
actually get things done while using it. I can't say I was expecting 
something full-stack like Django or Rails, but I wasn't expecting to have 
to write quite so much code to get simple things done. I've now spent 
around 14 hours building a RESTful web service that handles CRUD for a 
single database table because I've had to solve so many things I've come up 
against.

What I'm actually wondering here is what I'm missing. Is it that the entire 
clojurian approach is here are the pieces, build a framework from them or 
is it just that I've had terrible luck with libraries?

Some examples:
1. The :params key is used by ring.middleware.params, compojure and 
ring.middleware.format so it's impossible to know where a given param is 
coming from
2. ring.middleware.params does not provide a convenience map that merges 
:query-params and :form-params, despite being happy to stuff everything 
into :params. At least ring.middleware.format adds :body-params here. I've 
now written a middleware to do this.
3. ring.middleware.keyword-params only keywordises the :params map, not the 
other maps. There is no configurable behaviour to ask it to do other maps. 
I've now written a middleware for this
4. migratus seems to have the smallest note ever in the documentation 
informing you that version numbers must be 14 digits long (i was using 12 
digits for a timestamp by not having the seconds listed). This seems like a 
really daft requirement in the first place.
5. every migrations library i've seen that doesn't work off raw SQL files 
is incapable of representing advanced features of my database of choice 
(postgresql)
6. lobos requires varchars to have a length limit applied (postgres does 
not)
7. the best way i've found of dealing with a database is korma. While korma 
does reduce some of the pain of SQL for standard things, it has limits and 
it doesn't save all that much pain.

etc.

So, am I missing something? Are there any libraries people can recommend 
that will make my life easier? Am I just looking at this in completely the 
wrong way?

Thanks,
James

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Am I missing something?

2013-12-03 Thread James Laver 
Hi Sean,

On Wednesday, December 4, 2013 12:03:45 AM UTC, Sean Corfield wrote:

 Take a look at Liberator, which is specifically designed for building 
 REST APIs


I did have a quick look at liberator earlier but by that time i'd scratched 
most of my itch with compojure. I do intend to look into it in more depth 
though since there's a lot of application left to write.
 

 - but bear in mind the mindset of the Clojure community is 
 generally to compose several libraries to create the specific solution 
 you need, rather than having any full stack frameworks.


The lisp mindset is rather why I came over to clojure, but I wasn't 
expecting to have to write quite so much code to get on with things. 
 

 That said, 14 hours to create a RESTful web service for CRUD for a 
 single table seems excessive so I'd be curious exactly what you're 
 trying to achieve and why you're finding it so laborious? Perhaps if 
 you explain your requirements a bit more, we can offer better 
 suggestions...? 


I'm building a data management service for several other services to hang 
off. The basic problem is solves is to avoid having to either a) share the 
same database across multiple codebases (given that we may want to change 
the structure and then things get tedious) or b) keep several different 
databases (in which case welcome to synchronisation hell).

Part of the 14 hours has been a learning curve for the libraries involved. 
I also seem to have spent rather too patching what I perceive to be holes 
where facilities should be in the libraries I'm using and in writing 
abstractions to avoid some of the tedium. I didn't really imagine I'd write 
two data structure handling libraries, two pieces of middleware and a 
validation layer atop korma just to be able to do a little bit of CRUD.

I think I've been spoiled by the libraries available in other languages 
which seem to me to achieve a better balance between raw power and helping 
you to get things done more quickly (something I've found Perl achieves 
particularly well -- it errs on the side of power but the libraries seem 
more 'complete' if that makes sense).

Oh, I did find one library that I liked a lot, timbre.

James

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Am I missing something?

2013-12-04 Thread James Laver 

On 4 Dec 2013, at 09:06, James Reeves ja...@booleanknot.com wrote:

 It sounds like part of the issue is with ring.middleware.format overloading 
 the :params key, but it also seems like you might have an unusual set of 
 requirements.

Actually, my larger problem was with compojure doing it. I wanted a distinction 
between data coming from the route and data coming from the form data, since 
after vaidation, that gets shoved straight into the database.

 The custom middleware you describe sounds like one or two lines of code. Did 
 you find it took particularly long to write?

Ring is really wonderfully simple. the two combined take up only a handful of 
lines. Unfortunately, the tests take up rather a lot of lines (~140) and since 
they helped squeeze out the bugs, it would be a poor argument to say “don’t 
write them”.

See the source here https://gist.github.com/jjl/7785497

 Others have mentioned Liberator, which I'd highly recommend using for RESTful 
 web services. It gets rid of a lot of the boilerplate required, at least the 
 parts that deal with HTTP.

I think I’m going to have to look into it more fully.

James

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Am I missing something?

2013-12-04 Thread James Laver 

On 4 Dec 2013, at 05:00, David Nolen dnolen.li...@gmail.com wrote:

 Did you look at Caribou? It seems more like a complete solution - 
 http://let-caribou.in

I’ve now given this a look over. It seems insane. It makes quite a lot of (IMO) 
questionable choices and it doesn’t seem terribly pluggable.

James

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Am I missing something?

2013-12-04 Thread James Laver 

On 4 Dec 2013, at 11:00, Joshua Ballanco jball...@gmail.com wrote:

 Just a humble suggestion, but from a cursory glance at your tests, it seems 
 that something like simple-check might save you a lot of time in the future: 
 https://github.com/reiddraper/simple-check

That’s a much valued suggestion actually. I had been missing Haskell’s 
QuickCheck.

Cheers,
James

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Am I missing something?

2013-12-04 Thread James Laver 
On 4 Dec 2013, at 11:38, James Reeves ja...@booleanknot.com wrote:

 Compojure also adds to the :route-params key, so if you need to, you can 
 explicitly decide how you want maps of parameters to be merged. The :params 
 key is just there for the convenience of the majority of users.
 
 You could write something like:
 
 (POST /blah/:id [id :as {params :form-params}] ...)
 
 This would get the id from the routes (as they're always merged last), and 
 the parameters map from :form-params.

Hi James,

I’m pretty sure that’s the behaviour I was already seeing. Imagine this 
scenario:
- I access this route passing in the ID of the database record I wish to modify
- I pass in a new value for it in the post data (okay, bad example, you’re not 
likely to want to change an integer primary key, but bear with me)
- I then need access to not only the value of the id from the params but also 
the value from the post data, separately
- :form-params uses string keys not keywords so it then needs to be 
keywordified before it’s suitable for passing to the database layer (not to 
mention to make it significantly less of a pain to work with in userland code)

I think it’s mostly the effect of trying to use all of the pieces together 
that’s causing me some pain. I’ve now worked around it with the middleware I 
previously posted, but it was a little surprising that I had to.

Would you mind please explaining:
a: how that syntax deals with merges? I don’t quite understand what’s going on 
underneath. Does that actually bind to params?
b: how i could get those params extracted into a variable as well as access to 
the request map?

Cheers,
James

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Announcing oolong: a config-based glue for `component`

2015-03-18 Thread James Laver 
Responses inline :)

 On 18 Mar 2015, at 09:49, James Henderson ja...@jarohen.me.uk wrote:
  On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote:
  component’ is a difficult term to google for, so I hadn’t come across your 
  project :)
 
 Same problem here when I started writing Phoenix - there could be many 
 libraries trying to solve the same problem!

I think there’s a general danger of this when writing tools that solve generic 
problems. The problem of discoverability is something that I found a lot of 
when I was writing a lot of perl as well. If you weren’t attending events and 
keeping up to date with what’s going on, you didn’t get to hear about all the 
cool things people were doing. I find the clojure IRC channel helps a bit with 
this.

 Fair enough! I went for giving people the option of either one config file or 
 multiple (after all, you don't *have* to use :phoenix/includes!) mainly 
 because I got a lot of requests in Nomad (Phoenix's predecessor) for separate 
 apps within the same company to share common configuration.

*nod* I haven’t dealt with this yet. This is something my forthcoming library 
‘kombucha’ (that i’m supposed to be hacking on right now, ho hum…) will have to 
deal with as well. I’m currently trying to figure out the best way to deal with 
what leiningen calls profiles while keeping the configuration format sane and 
simple. I see you’ve got some support for that, so I’ll be having a look 
shortly.

 I see you note that phoenix is ‘batteries included’. That’s a great 
 experience for new users, but i wasn’t trying to build that on this occasion 
 :) The leiningen template and plugin are also nice additions, and reloaded 
 workflow integration is very handy.
 
 Hmm - Phoenix is 'batteries included, but removable' (phrasing stolen from 
 Docker) which is significantly different from 'batteries included'. I'm not a 
 fan of 'batteries included' - it tends to mean libraries that are hard for 
 users to customise at a later date, which (to me, and to you as well by the 
 sounds of it) goes against Clojure ideals. Phoenix is deliberately written as 
 a standalone runtime library, which composes with whatever other systems 
 people dream up, and a separate, lightweight plugin (not so composable), 
 which essentially just bootstraps the library and saves people the hassle of 
 a separate 'system.clj', 'dev.clj' and 'user.clj', if they so wish.

Yes. Sorry, I didn’t mean it as a negative comment. I think batteries included 
is great for getting people going quickly and I appreciate you’ve gone to some 
efforts to make it removable. However, you focus on the reloaded workflow 
aspect considerably in the documentation so I was under the assumption that was 
the case you were aiming to support.

 Happy to help with these - do you want to post some specifics? As a starting 
 point, I've found that including an 'emergency nREPL' - an nREPL that starts 
 before the application (and doesn't depend on the application compiling) gets 
 you a long way. If the application doesn't compile, the system doesn't start, 
 but I think that's actually preferable than half a system.
 
 Feel free to steal ideas from Phoenix - that's what open source is all about! 
 More than happy to work together on this as well though - seems like we have 
 both come to very similar conclusions about how we want to wire up Clojure 
 components.

I expect this could get lengthy so I’ll follow up offlist. More than happy to 
work together if our ideas coincide.

James

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Announcing oolong: a config-based glue for `component`

2015-03-18 Thread James Laver 
Hi James,

‘component’ is a difficult term to google for, so I hadn’t come across your 
project :)

I think your module had slightly different design goals from mine. Mine were:
* everything in one config file (although i also provide support for separate 
data-config and system config)
* be minimal. i’ve got a bunch of things i’m building on top of oolong at 
present that will together provide a more “complete” experience

I see you note that phoenix is ‘batteries included’. That’s a great experience 
for new users, but i wasn’t trying to build that on this occasion :) The 
leiningen template and plugin are also nice additions, and reloaded workflow 
integration is very handy.

Reloaded workflow has been an experience for me. I haven’t yet managed to get 
it working in the face of compile errors. I find myself restarting the 
leiningen repl about as much as before. For this reason I chose to keep it 
separate and delay dealing with it for a few weeks. Have you managed to 
overcome these problems? I’m definitely interested in knowing how if so.

I’ve only really given phoenix a few minutes of my attention so far, but I like 
what I see and I’m liable to steal ideas for some of the things i’ll be 
building on top of oolong. Feel free to reply offlist if you have any further 
questions.

James

 On 18 Mar 2015, at 09:07, James Henderson ja...@jarohen.me.uk wrote:
 
 Hi James,
 
 This looks very similar to Phoenix - a project I've been working on for the 
 last few months. It's pretty likely you hadn't heard of it (and that's fine - 
 it's not been hugely publicised!), but if you have, I was wondering whether 
 there was anything about it that you felt was missing/a bad design decision? 
 If so, would be great to get your feedback!
 
 Cheers,
 
 James
 
 On Tuesday, 17 March 2015 10:02:51 UTC, James Laver wrote:
 I've been using stuartsierra's handy component library for a while now, but I 
 wanted an easier way of connecting components together.
 
 To that end, I wrote oolong. The main mode of operation is to take an edn 
 configuration file and connect the specified systems and components.
 
 https://github.com/jjl/oolong
 
 https://clojars.org/oolong
 
 Feedback welcome. I spent quite a while documenting it so hopefully it should 
 be fairly clear to understand.
 
 James
 
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to a topic in the Google 
 Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/T_skapDqZ0U/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Announcing oolong: a config-based glue for `component`

2015-03-17 Thread James Laver 
I've been using stuartsierra's handy component library for a while now, but 
I wanted an easier way of connecting components together.

To that end, I wrote oolong. The main mode of operation is to take an edn 
configuration file and connect the specified systems and components.

https://github.com/jjl/oolong

https://clojars.org/oolong

Feedback welcome. I spent quite a while documenting it so hopefully it 
should be fairly clear to understand.

James

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Announcing oolong: a config-based glue for `component`

2015-03-17 Thread James Laver 
If nothing else, the functions in oolong.util should be pretty handy for 
manipulating them. Or can serve as a guide for manipulate them programmatically.

I’m working on a bunch of complementary stuff to this at present, including a 
library for developing components on top of oolong that will ease the 
transition between config-world and real-world, along with a bunch of 
components written to interoperate nicely. I’ve found that oolong simplifies 
interop in one major regard: specifying everything as nested maps means 
functions to start components will always take one argument. I’ve seen a lot of 
libraries do this to solve this problem.

James

 On 17 Mar 2015, at 23:04, Andrew Oberstar ajobers...@gmail.com wrote:
 
 Just a quick look so far, but it looks pretty interesting. I'm working on a 
 multi-module project and I'd like to have the flexibility to run those 
 modules separately or together. Extracting the component structure out into a 
 config file could be pretty helpful in that regard. Nice work!
 
 Andrew Oberstar

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

[ANN] ednsl-0.2.0: a super-simple DSL for building DSLs

2015-04-03 Thread James Laver 
It’s not quite as stupid as it sounds and it’s mostly the result of factoring 
out the config handling code from oolong[1]

https://github.com/jjl/ednsl/
https://clojars.org/ednsl

Happy hacking!

James

[1] https://github.com/jjl/oolong/


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] oolong-0.3.0

2015-04-14 Thread James Laver 
Hi,

Oolong has had a version bump to 0.3.0 which incorporates a refactor to using 
my new tv100 library (for transformation and validation of data structures). 
Hopefully this will make it easier to build on top of.

The artifact has now moved into the ‘irresponsible’ group to mirror the github 
organisation that owns this.

https://github.com/irresponsible/oolong
https://clojars.org/irresponsible/oolong

/j

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Raynes' legacy

2017-02-24 Thread James Laver 
I'm pleased we've dealt with a new maintainer for a couple of Raynes' 
modules, but Raynes contributed a lot of things and half the community 
depends on one or more of his modules at this point.

My current focus is tentacles, which has been gathering issues and PRs 
recently and is something I'm about to use in a project. If no-one else 
steps forward, we at the irresponsible clojure guild ( 
https://github.com/irresponsible ) will take on the maintenance for it, but 
we don't want to end up causing multiple forks.

I think it would be awesome if *somebody* would step up and take care of 
Raynes' remaining modules. Aside from being his legacy, they're really 
useful and too many of rely on them. Irresponsible is a community-run 
organisation (currently just three of us). If more people were willing to 
pitch in with reviewing PRs and issues and such, we would be happy to 
assume responsibility for releases. In effect, we're happy to keep Raynes' 
work alive rather than bitrotting. But we can't do all of that alone, it's 
just too much work (something other contributors have noted). We are happy 
to give them a home and push releases, but there are simply too many of 
them to take up proper maintenance without more volunteers

So, with that:

1. Does this seem like a good idea?
2. Can you help with reviewing the backlog on Raynes' modules?
3. Is this going to be enough to prevent multiple forks of everything?

Cheers,
James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Raynes' legacy

2017-02-27 Thread James Laver 
Hi Matthew,

On Monday, February 27, 2017 at 5:11:19 AM UTC+1, Matthew Boston wrote:
>
> I'm happy to hear that others are willing to step up to the plate in 
> regards to continuing Anthony's legacy.
>
> I started a thread specifically about tentacles a month ago here: 
> https://groups.google.com/forum/#!searchin/clojure/tentacles%7Csort:relevance/clojure/15x_LWE2IMM/CGULJTXLBQAJ
>

Ah yes, I remember it, I had merely forgotten it was about tentacles :)
 

> We, at CircleCI, have built our entire business around the use of 
> tentacles, so seeing this library succeed is paramount to our success. 
> Right now, we're on an older version of tentacles and we're currently 
> working to upgrade to the latest so we can begin to maintain a fork; or at 
> the very least, help others in maintaining a "de facto fork".
>

This is for an open source project I will be starting work on soon, not 
something business critical, but on the bright side, it'll be "up to date" 
when I start. 

Personally I'd be quite happy to see CircleCI take over maint of tentacles. 
You have a trusted name and reputation and you have a good incentive to 
keep improving the code. We will still offer to take whatever of Raynes' 
modules people haven't started maintaining de facto forks of.

Cheers,
James

On Saturday, February 25, 2017 at 12:09:02 AM UTC-7, James Laver wrote:
>
> I'm pleased we've dealt with a new maintainer for a couple of Raynes' 
> modules, but Raynes contributed a lot of things and half the community 
> depends on one or more of his modules at this point.
>
> My current focus is tentacles, which has been gathering issues and PRs 
> recently and is something I'm about to use in a project. If no-one else 
> steps forward, we at the irresponsible clojure guild ( 
> https://github.com/irresponsible ) will take on the maintenance for it, 
> but we don't want to end up causing multiple forks.
>
> I think it would be awesome if *somebody* would step up and take care of 
> Raynes' remaining modules. Aside from being his legacy, they're really 
> useful and too many of rely on them. Irresponsible is a community-run 
> organisation (currently just three of us). If more people were willing to 
> pitch in with reviewing PRs and issues and such, we would be happy to 
> assume responsibility for releases. In effect, we're happy to keep Raynes' 
> work alive rather than bitrotting. But we can't do all of that alone, it's 
> just too much work (something other contributors have noted). We are happy 
> to give them a home and push releases, but there are simply too many of 
> them to take up proper maintenance without more volunteers
>
> So, with that:
>
> 1. Does this seem like a good idea?
> 2. Can you help with reviewing the backlog on Raynes' modules?
> 3. Is this going to be enough to prevent multiple forks of everything?
>
> Cheers,
> James
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Clojure advent calendar: call for contributions

2016-10-09 Thread James Laver 
Hi all,

In the model of http://perladvent.org/2015/ and many other "let's look at a 
programming shiny every day" projects, I thought I'd try to do a clojure 
advent this year. The overall theme for this year is planned to be a 
showcase libraries available on clojars, so every day we'll do something 
practical/fun/astonishing/elegant with a library or two from clojars.

If you're interested in contributing a day, please let me know offlist. Let 
your imagination run wild and let's get some people wanting clojure books 
for christmas!

Cheers,
James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure advent calendar: call for contributions

2016-10-15 Thread James Laver 
(bump)

At the minute, including myself there are five volunteers. If we don't get 
a few more, we just won't have enough material to do this, which would be a 
shame.

Come on clojure community, we can do this!

/j

On Sunday, October 9, 2016 at 2:00:41 PM UTC, James Laver wrote:
>
> Hi all,
>
> In the model of http://perladvent.org/2015/ and many other "let's look at 
> a programming shiny every day" projects, I thought I'd try to do a clojure 
> advent this year. The overall theme for this year is planned to be a 
> showcase libraries available on clojars, so every day we'll do something 
> practical/fun/astonishing/elegant with a library or two from clojars.
>
> If you're interested in contributing a day, please let me know offlist. 
> Let your imagination run wild and let's get some people wanting clojure 
> books for christmas!
>
> Cheers,
> James
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Spec of conform of spec

2016-12-10 Thread James Laver 
This is exactly my use case as well. I want to provide the user a nice DSL 
but make it easy to automatically generate input. The idea I had was the 
user could write things in the DSL and for automatic generation you could 
just generate the conformed structure.

The other thing it's made me notice is that we really need a library to 
make errors clearer in large nested data structures.

/j

On Saturday, December 10, 2016 at 3:09:24 AM UTC+1, Leon Grapenthin wrote:
>
> Alex, I thought about this and it appears to be a convenience problem. 
> Spec is e. g. excellent to parse a e. g. a Query DSL (which is my current 
> side project) via conform. But then you have that large data structure that 
> you want to break down and operate on in several functions. So you need to 
> have the specs for the conformed structure built by spec. 
>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] oolong 0.4.0 - the cljs support release

2016-12-09 Thread James Laver 
Hi all,

We added cljs support to oolong and tidied it up a little bit. We now 
require clojure 1.7 for cljc support.

https://github.com/irresponsible/oolong/

At this point oolong is considered relatively stable and is transitioning 
to maintenance mode, so we're still happy to take patches, but we won't be 
actively developing it.

Happy hacking!

James


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] irresponsible/codependence 0.1.0 (dependency resolution for apps - a twist on integrant)

2017-03-19 Thread James Laver 
Hi all,

The Irresponsible Clojure Guild is pleased to announce codependence 0.1.0 
is now available on clojars.

This library came about because I liked integrant, but I wanted a bit more 
flexibility. It's built upon integrant (which is cool, I ported it to 
clojurescript!) but with a twist.

In ordinary integrant, you might specify an app like this (component 
configs elided for brevity):

```
{:http {}
 :db {}}
```

In codependence you specify them like this:

```
{:http {:co/tag :http/aleph}
 :db {:co/tag :db/utrecht}
```

In the first example, :http and :db are the tags one will register 
behaviour for. in the second, they are :http/aleph and :db/utrecht. 
integrant refs are unmodified

This firstly means that one tag can instantiate multiple components of the 
same type and secondly makes it easier to ship predefined components and 
let a user stitch them together as config

dep coord: [irresponsible/codependence "0.1.0"]
github: https://github.com/irresponsible/codependence

Cheers,
James (and the ICG)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] tentacles fork on clojars - raynes' legacy lives on!

2017-03-18 Thread James Laver 
Oops, that went out with a boot-test dependency (thanks for the spot, coda 
hale!)

Please find [irresponsible/tentacles "0.6.1"] on clojars.

And this time I'll spell 'github' correctly: 
https://github.com/irresponsible/tentacles

/j

On Saturday, March 18, 2017 at 9:19:08 AM UTC+1, James Laver wrote:
>
> Hi all,
>
> Further to previous discussions, we (the irresponsible clojure guild) have 
> forked tentacles and intend to keep it maintained and improved.
>
> This is our first release of tentacles under the irresponsible group and 
> we have resumed versioning from Raynes' versions.
>
> github: https://gthub.com/irresponsible/tentacles/
> dep coord: [irresponsible/tentacles "0.6.0"]
>
> Changelog:
>
>- Reviewed every open bug and pull request
>- Merged the majority of PRs, did the rest ourselves
>- Bumped deps and updated docs
>- Started keeping changelog
>- Fixed reported documentation issues
>- Moved to boot so we can ship it like any other irresponsible lib
>
> Bugs fixed:
>
>- Requests error out when the body is not json 
><https://github.com/Raynes/tentacles/issues/81>
>- Update to new watch endpoint 
><https://github.com/Raynes/tentacles/pull/109>
>- Conditional request and :all-pages true option didn't play nicely 
><https://github.com/Raynes/tentacles/pull/110>
>- Collection responses have an extra empty map as the last element 
><https://github.com/Raynes/tentacles/issues/64>
>
> Features added:
>
>- Notifications api <https://github.com/Raynes/tentacles/pull/93>
>- Reactions api <https://github.com/Raynes/tentacles/issues/96> (GET 
>only at present)
>
>
> Finally, a massive shout out to the other main contributor of the ICG, 
> Kent Fredric, who managed to get this release out despite tripping over a 
> bunch of boot failure in the process.
>
>
> Cheers,
>
> James
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] irresponsible/codependence 0.1.0 (dependency resolution for apps - a twist on integrant)

2017-03-20 Thread James Laver 
Hi James,

It's nice to see that integrant now has support for multiple 
instantiations, good job!

I think it doesn't mean much for codependence though as I'm likely to 
extend it with more features soon that probably don't belong in integrant.

Cheers,
James

On Monday, March 20, 2017 at 8:44:16 AM UTC+1, James Reeves wrote:
>
> Nice work. The use of keys is interesting.
>
> I'm not sure of this affects Codependence, but I released a new version of 
> Integrant a few days ago that supports multiple components of the same type 
> via composite keys.
>
> - James
>
> On 19 March 2017 at 09:17, James Laver <james...@gmail.com > 
> wrote:
>
>> Hi all,
>>
>> The Irresponsible Clojure Guild is pleased to announce codependence 0.1.0 
>> is now available on clojars.
>>
>> This library came about because I liked integrant, but I wanted a bit 
>> more flexibility. It's built upon integrant (which is cool, I ported it to 
>> clojurescript!) but with a twist.
>>
>> In ordinary integrant, you might specify an app like this (component 
>> configs elided for brevity):
>>
>> ```
>> {:http {}
>>  :db {}}
>> ```
>>
>> In codependence you specify them like this:
>>
>> ```
>> {:http {:co/tag :http/aleph}
>>  :db {:co/tag :db/utrecht}
>> ```
>>
>> In the first example, :http and :db are the tags one will register 
>> behaviour for. in the second, they are :http/aleph and :db/utrecht. 
>> integrant refs are unmodified
>>
>> This firstly means that one tag can instantiate multiple components of 
>> the same type and secondly makes it easier to ship predefined components 
>> and let a user stitch them together as config
>>
>> dep coord: [irresponsible/codependence "0.1.0"]
>> github: https://github.com/irresponsible/codependence
>>
>> Cheers,
>> James (and the ICG)
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] tentacles fork on clojars - raynes' legacy lives on!

2017-03-18 Thread James Laver 
Hi all,

Further to previous discussions, we (the irresponsible clojure guild) have 
forked tentacles and intend to keep it maintained and improved.

This is our first release of tentacles under the irresponsible group and we 
have resumed versioning from Raynes' versions.

github: https://gthub.com/irresponsible/tentacles/
dep coord: [irresponsible/tentacles "0.6.0"]

Changelog:

   - Reviewed every open bug and pull request
   - Merged the majority of PRs, did the rest ourselves
   - Bumped deps and updated docs
   - Started keeping changelog
   - Fixed reported documentation issues
   - Moved to boot so we can ship it like any other irresponsible lib

Bugs fixed:

   - Requests error out when the body is not json 
   
   - Update to new watch endpoint 
   
   - Conditional request and :all-pages true option didn't play nicely 
   
   - Collection responses have an extra empty map as the last element 
   

Features added:

   - Notifications api 
   - Reactions api  (GET 
   only at present)


Finally, a massive shout out to the other main contributor of the ICG, Kent 
Fredric, who managed to get this release out despite tripping over a bunch 
of boot failure in the process.


Cheers,

James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] new release: irresponsible/anarchy 0.1.0 - logic without rules

2017-04-06 Thread James Laver 
The primary purpose of this library is to provide a model you can build a 
UI around that programmers and non-programmers alike can grok.

Dep (clojars): [irresponsible/anarchy "0.1.0"]

More information (and diagrams!) on github: 
https://github.com/irresponsible/anarchy

Cheers,
James (and the Irresponsible Clojure Guild)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] irresponsible/anarchy (business logic engine driven by tabular data) v0.2.0

2017-05-11 Thread James Laver 
The Irresponsible Clojure Guild is pleased to announce a new version of the 
'anarchy' business logic engine. This version features better resistance 
against nil-returning predicates and completely rewritten documentation 
that is hopefully significantly easier to understand.

The docs are still a work in progress. Please file issues if you have 
difficulty understanding anything.

dep coord: [irresponsible/anarchy "0.2.0"]
github: https://github.com/irresponsible/anarchy

Cheers,
James (and the rest of the guild)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.