Re: New to Clojure

[simon lomax]

As far as SQL libraries for Clojure are concerned I would highly recommend 
HugSQL . Comprehensive documentation and a 
pleasure to use.

Good luck with your project.

regards,
Simon 

On Monday, 9 January 2017 23:06:30 UTC, (hash-map :new "to clojure" :need 
"assistance") wrote:
>
> Hi all!
>
> So, I'm new to Clojure! I'm coming in from a Java background and am 
> currently working on a project that has prompted me to have a look at 
> whether Clojure would be useful. 
> I have started by going through the "Brave Clojure" website and working 
> through the exercises and what I've seen has at many times just made me 
> smile at the (at least so far) intuitiveness, simplicity and power of the 
> language. My use case is this:
>
> A real time (sealed bid) auctioning system. We have a maximum number of 
> bids (example 100) that's set by the owner of the product. Our clients then 
> bid on the product. Once a bid is made, it's committed to a database and 
> the counter increments. The next bid is processed, and so on. Once the 
> maximum number of bids is reached, bidding stops. This auctioning system is 
> for a mobile application however the main code for the real time system 
> sits on a web server. The mobile app is a very thin client so simply makes 
> a call to the app server via an API which then processes that request (and 
> returns the result). 
>
> Requests are processed in order - so we're following a "first come first 
> serve" approach. If at any time a request is due to be processed and the 
> counter hits 100, all requests should gracefully "fail" and be blocked from 
> bidding. Now this is obviously possible in Java, albeit with a lot more 
> code and thinking about the different ways to make everything thread-safe, 
> etc. This is a completely new project so there's no restriction on 
> languages to be used, etc. PS: We're all Java developers.
>
> I was really attracted to Clojure because of a) the JVM b) the fact that 
> it seems to be able to handle concurrency effortlessly c) our API needs to 
> scale and so we want to ensure that we can handle the 100K+ connections 
> easily when the project reaches that stage. Obviously this is more to do 
> with the hardware, but the way we build the API is a definite factor. 
> Finally, there seems to be less verbose codebases on Clojure and it might 
> help to keep our overall codebase light and readable! 
>
> My questions therefore are these:
>
> With the time we have (around 1 month for this stage), is this something 
> we can easily build in Clojure?
> Is the movement from Java to Clojure easy for someone completely new to 
> Clojure?
> Are the libraries that we might use for this - I had a look at Ring 
> briefly robust for our use case?
> Does Clojure have good support for using AWS for example? (You can call 
> Java from Clojure so I guess this wouldn't really be an issue.)
> Does it interface well with MySQL?
>
> I'd be very grateful if someone could point me in the right direction on 
> this - like I said, really really like what I'm seeing of Clojure but just 
> want to be sure from the community before I recommend this as an action to 
> take!
>
> (hash-map :many "thanks")
>
>

-- 
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: New to Clojure

[Gregg Reynolds]

On Jan 9, 2017 5:06 PM, "(hash-map :new "to clojure" :need "assistance")" <
nas@gmail.com> wrote:

Hi all!

So, I'm new to Clojure! I'm coming in from a Java background and am
currently working on a project that has prompted me to have a look at
whether Clojure would be useful.
I have started by going through the "Brave Clojure" website and working
through the exercises and what I've seen has at many times just made me
smile at the (at least so far) intuitiveness, simplicity and power of the
language. My use case is this:

A real time (sealed bid) auctioning system. We have a maximum number of
bids (example 100) that's set by the owner of the product. Our clients then
bid on the product. Once a bid is made, it's committed to a database and
the counter increments. The next bid is processed, and so on. Once the
maximum number of bids is reached, bidding stops. This auctioning system is
for a mobile application however the main code for the real time system
sits on a web server. The mobile app is a very thin client so simply makes
a call to the app server via an API which then processes that request (and
returns the result).

Requests are processed in order - so we're following a "first come first
serve" approach. If at any time a request is due to be processed and the
counter hits 100, all requests should gracefully "fail" and be blocked from
bidding. Now this is obviously possible in Java, albeit with a lot more
code and thinking about the different ways to make everything thread-safe,
etc. This is a completely new project so there's no restriction on
languages to be used, etc. PS: We're all Java developers.


you might want to take a look at the awesome
https://github.com/ztellman/aleph

-- 
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: New to Clojure

[Gregg Reynolds]

On Jan 9, 2017 5:06 PM, "(hash-map :new "to clojure" :need "assistance")" <
nas@gmail.com> wrote:

Hi all!

So, I'm new to Clojure! I'm coming in from a Java background and am
currently working on a project that has prompted me to have a look at
whether Clojure would be useful.
I have started by going through the "Brave Clojure" website and working
through the exercises and what I've seen has at many times just made me
smile at the (at least so far) intuitiveness, simplicity and power of the
language. My use case is this:

A real time (sealed bid) auctioning system. We have a maximum number of
bids (example 100) that's set by the owner of the product.


just curious, I don't know this market, but why set a limit on bids?

gregg

-- 
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 and à la carte conformance of map vals (and maybe a bug)

[Sean Corfield]

At World Singles, we use clojure.spec for that scenario: conforming / 
validating string input data and producing non-string conformed values.

 

For each string-to-non-string type, we write a conformer that accepts the 
string and either produces the valid, parsed non-string valid or produces 
::s/invalid. If we need further constraints on the non-string value, we use 
s/and to combine those.

 

We also have generators for all of these: we use gen/fmap of a 
non-string-to-string formatter over a (custom) generator for the non-string 
values.

 

Here’s an example, for string input representing dates:

 

(defn coerce->date

  "Given a string or date, produce a date, or throw an exception.

  Low level utility used by spec predicates to accept either a

  date or a string that can be converted to a date."

  [s]

  (if (instance? java.util.Date s)

    s

    (-> (tf/formatter t/utc "/MM/dd" "MM/dd/"

  "EEE MMM dd HH:mm:ss zzz ")

    (tf/parse s)

    (tc/to-date

 

(defn ->date

  "Spec predicate: conform to Date else invalid."

  [s]

  (try (coerce->date s)

   (catch Exception _ ::s/invalid)))

 

(defmacro api-spec

  "Given a coercion function and a predicate / spec, produce a

  spec that accepts strings that can be coerced to a value that

  satisfies the predicate / spec, and will also generate strings

  that conform to the given spec."

  [coerce str-or-spec & [spec]]

  (let [[to-str spec] (if spec [str-or-spec spec] [str str-or-spec])]

    `(s/with-gen (s/and (s/conformer ~coerce) ~spec)

   (fn [] (g/fmap ~to-str (s/gen ~spec))

 

(s/def ::dateofbirth (api-spec ->date #(dt/format-date % "MM/dd/") inst?))

 

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 1/13/17, 9:56 PM, "Josh Tilles"  wrote:

 

Alex,

 

Thank you for your reply! (I apologize for the delay in my own.)

 

I’ll first address your final point (regarding what spec is buying me vs. just 
using normal functions): I’m still trying to figure that out myself! 😁 I.e., 
the boundaries of spec’s applicability/appropriateness are not yet apparent to 
me.

 

Second, your suggestion of an explicit coercion step before using spec to 
validate the map indicates to me that we were envisioning different things, 
although perhaps I’ve misunderstood the role of spec’s conformers. I was 
thinking about a situation like processing maps of named timestamps that 
originated as JSON sent over HTTP. The maps’ JSON origins force the timestamp 
values to be strings, but it would be a lot more convenient for downstream 
processing if the timestamps were in a format more structured than a string, 
like a map (akin to how s/cat specs conform, perhaps with :year, :month and 
:day components) or even an org.joda.time.DateTime instance. Hence, in this 
hypothetical code, I’d like to ensure the strings nested in the maps look 
properly timestamp-y before preparing the data for downstream processing by 
converting the strings to the more-structured format. So the coercions I had in 
mind would make more sense as a post-step to validation, but does this seem 
like an inappropriate application of conformers to you? I’d thought that 
s/conform was meant for this kind of validate-then-convert behavior, but I see 
how coercion before validation would be valuable in a different way, enabling 
more-granular specification, with more-focused predicate implementations and 
more-precise error reporting.

 

Ultimately, I’m trying to discern which of the following scenarios is the case:

· I’m misusing spec by trying to “opt in” to using conformers on map 
values.

· I’m using spec appropriately and the ability to specify conformance à 
la carte is a feature worthy of consideration.

· I’m using spec appropriately and the inability to specify conformance 
à la carte is unfortunate yet tolerable & unlikely to change.

 

>From what you wrote before, it seems likely that either the first or the third 
>is true, but I wanted to make sure I wasn’t being misunderstood first.

 

Thank you,

Josh

 

 

On Dec 19, 2016, at 5:26 PM, Alex Miller  wrote:

 

On Monday, December 19, 2016 at 2:42:49 PM UTC-6, Josh Tilles wrote:

1. Is this seen as an acceptable tradeoff of an API that the core Clojure 
devs are otherwise happy with? Or is it in fact a deliberate limitation, in 
line with the “map specs should be of keysets only”design decision?

It is deliberate that s/keys works only on attributes and that you can't inline 
value specs.

Right, and that’s a decision that I’m not contesting, btw.



You could still do individual transformations by conforming non-registered 
specs if desired.

Do you mean that I could s/conform maps against an “anonymous” spec like (s/and 
::something (s/conformer #(try (update % ::created timestamp->map) (catch 
SomeExcep

[ANN] Hiccup 2.0.0-alpha1

[James Reeves]

I'd like to tentatively announce the first alpha version of Hiccup 2.0.0.

This release introduces automatically escaping of strings, which has been a
frequently requested feature. Hiccup 1.0 had no way of distinguishing
between a string of text and a fragment of HTML, so for version 2.0 a new
type has been introduced to represent the latter.

A lot of projects depend upon Hiccup, and after thinking about it for a
while, and watching Rich's Spec-ulation
 talk, I decided to introduce
a new namespace rather than break backward compatibility. So although
Hiccup 2.0.0 is a major version change, it should be backward compatible
with version 1.0.

The new namespace is hiccup2.core, and it works like this:

  (require '[hiccup2.core :refer [html raw]])

  (str (html [:span "one < two"]))
  ;=> "one < two"

Notice that now strings are escaped by default, but we also need to
explicitly convert the HTML fragment into a string by using clojure.core/str
.

By using a compiled intermediate format, we gain a lot more potential
flexibility. For example, possible future feature currently under
consideration is to support different ways of formatting the HTML. Using an
intermediate format allows us to do this after pre-compilation has taken
place.

Because this is an alpha release, the hiccup2.core namespace is not set in
stone, but it does seem to be the simplest solution to the problem of
incompatibility. Suggestions for better ways to solve this are welcome and
encouraged.

As well as escaping strings, additional syntax sugar for attributes has
been introduced. This should be familiar to anyone using Reagent:

  (str (html [:span {:class ["foo" "bar"]} "example"]))
  ;=> "example"

  (str (html [:span {:style {:color "red"}} "example"]))
  ;=> "example"

Please give the alpha release a spin, and if there are any
incompatibilities please let me know.

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