[ANN] Tupelo - Clojure With A Spoonful of Honey

[Alan Thompson]

​​
Version  0.9.39 of the Tupelo library 
has been released.

Tupelo is a library of helper and convenience functions to make working
with Clojure simpler, easier, and more bulletproof.

I've been working on some parsing & validation code recently and had
occasion to use a very handy function in the unit tests.  Often during
testing we wish to validate only part of a return value, and ignore certain
parts that are non-deterministic or otherwise non-diffable.  Think of
values like a timestamp, UUID, or the `#db/id` value in Datomic.  The value
of fields like these cannot be predicted in advance and are normally not
germane to problem under test.

In my problem, I have been making small "records" that look like this:


[:range {:low low
 :highhigh
 :fn-validate (fn [arg] (<= low arg high))}]


In this case, I can't just do an equals comparison in a unit test since one
cannot easily compare a function object to see if it is the expected value.
One could use `extract-keys` or similar and test a derived record, but that
is extra work (esp. for nested arrays & maps) and obscures the simple goal
of the test.

Enter the Tupelo function `wild-match`
.  It
allows one to use a wild card :* to ignore values in a vector and/or map
that we don't care about.  In this case we can write the tests:

(is (wild-match? [:range {:low  123 :high 456 :fn-validate :*}] (parse-
and-transform "123..456")))
(is (wild-match? [:range {:low  123 :high 456 :fn-validate :*}] (parse-
and-transform "123 .. 456")))
(is (wild-match? [:range {:low  123 :high 456 :fn-validate :*}] (parse-
and-transform "  123 .. 456 ")))
(is (wild-match? [:range {:low -123 :high -45 :fn-validate :*}] (parse-
and-transform "-123..-45")))

We just use the :* wildcard to ignore the fields we don't care about, and
`wild-match?` takes care of the rest. Note that it works equally well on
vectors & on maps.  The function signature is:

(wild-match? pattern & values)


Note that, since we put the pattern first, we can match multiple data
values simultaneously:

(wild-match?  {:a :* :b 2}
  {:a 1  :b 2}) ;=> true

(wild-match?  [1 :* 3]
  [1 2  3]
  [1 9  3] ))   ;=> true

(wild-match?  {:a :*   :b 2}
  {:a [1 2 3]  :b 2})   ;=> true


Enjoy,
Alan

-- 
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: Monorepos with separate artifacts?

[Sean Corfield]

FWIW, at World Singles, we have a monorepo for all our backend code and we use 
Boot to manage dependencies and the build process.

 

We have divided the code into subprojects, each with its own src/resources/test 
folders and a deps.edn file specifying the external dependencies.

 

We have Boot tasks that, given a target subproject, perform a namespace 
dependency analysis across all the subprojects and identify the minimal set of 
artifacts needed to test / run / build that subproject. We build an uberjar 
from each of six of those subprojects. They’re mostly about 20MB each (we don’t 
AOT – that would definitely bloat things).

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

On 4/30/17, 3:40 PM, "Laurens Van Houtven"  wrote:

 

I have a project with several components. Parts are a pretty standard Clojure 
programs with logically separate but related functionality, parts are 
ClojureScript intended for web browsers, and in the future parts might be React 
Native ClojureScript. There are good code-sharing reasons for keeping them in 
one codebase, but that also comes with a lot of downsides.



Uberjar size is one. There are lots of reasons to want to reduce jar size, 
including performance, but in my case it's also a design constraint. AWS Lambda 
only gives you a 50MB budget. The jars for all AWS APIs add up to something 
just north of that already, and for reasons beyond my comprehension AWS doesn't 
make them available on the classpath the same way they do for non-JVM runtimes. 
A part of my code just talks to AWS services, but in the simplest possible 
project.clj, it'll also be lugging e.g. ClojureScript around. Parts use 
datascript, but others don't.




Unfortunately in my experience using minimizers like ProGuard with uberjars 
turns out to be a great way to get a tiny jar that doesn't work. (I know some 
folks are experimenting with that to make that better.)



It seems that the most popular approach to an application that has a lot of 
components is a cluster of separate repos, or at least independent directories 
within a single repository. Does anyone have any experience with a single 
codebase that produces a few different artifacts; say, a few different 
uberjars, some static JS files and maybe an Android/iOS deployable? Was it a 
giant pain in the neck? Is boot helpful at all here? Doing this with lein 
profiles feels a little gauche.





lvh

-- 
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.


-- 
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.

Monorepos with separate artifacts?

[Laurens Van Houtven]

I have a project with several components. Parts are a pretty standard Clojure 
programs with logically separate but related functionality, parts are 
ClojureScript intended for web browsers, and in the future parts might be React 
Native ClojureScript. There are good code-sharing reasons for keeping them in 
one codebase, but that also comes with a lot of downsides.

Uberjar size is one. There are lots of reasons to want to reduce jar size, 
including performance, but in my case it's also a design constraint. AWS Lambda 
only gives you a 50MB budget. The jars for all AWS APIs add up to something 
just north of that already, and for reasons beyond my comprehension AWS doesn't 
make them available on the classpath the same way they do for non-JVM runtimes. 
A part of my code just talks to AWS services, but in the simplest possible 
project.clj, it'll also be lugging e.g. ClojureScript around. Parts use 
datascript, but others don't.

Unfortunately in my experience using minimizers like ProGuard with uberjars 
turns out to be a great way to get a tiny jar that doesn't work. (I know some 
folks are experimenting with that to make that better.)

It seems that the most popular approach to an application that has a lot of 
components is a cluster of separate repos, or at least independent directories 
within a single repository. Does anyone have any experience with a single 
codebase that produces a few different artifacts; say, a few different 
uberjars, some static JS files and maybe an Android/iOS deployable? Was it a 
giant pain in the neck? Is boot helpful at all here? Doing this with lein 
profiles feels a little gauche.


lvh

-- 
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] graphql-clj 0.2.0

[Matthew Boston]

The first, and biggest difference that I see, is that a schema is defined 
as a single string in graphql-clj, but Lacinia uses data structures to 
describe your graphql schema. The latter being more easily composable, if 
that's something you need.

On Monday, April 24, 2017 at 8:29:24 PM UTC-6, Didier wrote:
>
> How does this compare to Lacinia?
>
> On Monday, 24 April 2017 11:24:22 UTC-7, Lei wrote:
>>
>> graphql-clj is a Clojure library that provides GraphQL implementation.
>>
>> In this new version 0.2.0,  schema and query validator have been 
>> completely rewritten for simplicity and robustness. APIs have simplified in 
>> this new version as well.
>>
>> The github repository is: https://github.com/tendant/graphql-clj
>>
>> Any comments and advices are welcome!
>>
>> Cheers,
>> Lei
>>
>

-- 
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: Rust intro for Clojurists

[Colin Yates]

+1 :-)

On 30 April 2017 at 14:40, Herwig Hochleitner  wrote:
> 2017-04-30 2:24 GMT+02:00 Alan Thompson :
>>
>> https://gist.github.com/oakes/4af1023b6c5162c6f8f0
>
>
> ,,Many people try to compare Rust to Go, but this is flawed. Go is an
> ancient board game that emphasizes strategy.''
>
> This made me actually LOL. Instant classic! Please write more, Mr. Oakes!
>
> --
> 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.

-- 
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: Rust intro for Clojurists

[Herwig Hochleitner]

2017-04-30 2:24 GMT+02:00 Alan Thompson :

> https://gist.github.com/oakes/4af1023b6c5162c6f8f0
>

,,Many people try to compare Rust to Go, but this is flawed. Go is an
ancient board game that emphasizes strategy.''

This made me actually LOL. Instant classic! Please write more, Mr. Oakes!

-- 
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.