This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (59)
- # aws (27)
- # beginners (42)
- # boot (22)
- # cider (5)
- # clojure (97)
- # clojure-australia (3)
- # clojure-italy (2)
- # clojure-japan (9)
- # clojure-russia (81)
- # clojure-sg (2)
- # clojurescript (86)
- # clojutre (1)
- # cloxp (2)
- # cursive (60)
- # datomic (24)
- # docs (1)
- # editors (1)
- # emacs (17)
- # hoplon (57)
- # instaparse (1)
- # jobs (11)
- # ldnclj (19)
- # re-frame (1)
- # reagent (3)
- # spacemacs (7)
- # testing (8)
- # yada (127)
@danielcompton @akiva @seancorfield yep, same experience here. also they were super pushy in making me write that book. since then I am highly skeptical about them. also they asked me to write about a topic which was already covered by one of their books....
I sent back the last two packt books i bought and will never buy one again. They are just crappy publishers.
I reviewed one of the early packt clojure books and the process was such a catastrophe that I turned it down and refused to have my name somewhere on it. (This is not a criticism of the author)
Someone done a codility test once? Unfortunately Clojure is not an option. But there is a request for it on which can be voted (https://codility.com/programmers/)!
guys can you suggest api testing libs for clojure web api testing, i am using pedestal with friend as web framework and suggestion for unit-testing and datomic query testing
We just use
clj-http for testing an HTTP API — and write a little DSL for commands around the API — and
clj-webdriver for testing at a UI level.
@piyushmandovra: I’ve used peridot and ring-mock in the past (though, those applications were not using pedestal)
@jakemcc yup i was looking for ring mock but not able to figure out how to use them with pedestal app, help me if you understand
@seancorfield can you elaborate more about dsl commands and your clj-http testing architecture?
Not sure what more you’re looking for? We call
post functions with the API URLs and test we get back what we expect. The DSL is written in terms of actions within our application to call API endpoints as appropriate.
Funny, I was just doing a Google search on "clojure lookahead" and what should pop up but the Packt book on Google Books: https://books.google.com/books?id=dQtnCgAAQBAJ&printsec=frontcover
@akiva: ^ What I've seen of the book on Google books isn't that good. Don't think I'd be happy if I spent $$ for it.
@akiva: Play with L-Systems - they're fun: https://github.com/decomplect/ion/blob/master/src/ion/ergo/l_system.cljc
I need to change that description since the ergo library works with both Clojure and ClojureScript.
Okay, they're not too much fun now, but I had to lay the foundation. They will be fun when I'm done with them.
I'm not super happy with how I'm handling the need to do a "look ahead" when processing a collection.
I feel like its taken me even further away from being able to really leverage transducers.
I can explain it in 30 seconds because it is so easy to do them in a nice functional language like clojure.
The basic idea is that you have a rewriting system that takes an initial collection of values (or just one value), like
[:A], you process each "letter" or item in the collection, using it to look up a value in some rules (a map) and if there is a match you substitute the new value for the old, or retain the original if there is no match.
Then you repeat that recursively. And your collection grows like crazy:
(count (nth foo-modules 11)) => 354293 (count (nth foo-modules 12)) => 1062881
Interesting. See, this is a whole new geography of interesting stuff to explore for me.
an L-System is a specific rewriting system that flattens out the collection each time through, and it does all of its replacements at once (well, in sequence).
Yeah, I’m looking at the examples on Wikipedia (the page is surprisingly good) and comparing it to what you’re typing.
Now, to make it more powerful you want to do parametric substitutions where some parameters go along for the ride. So I allow the "letters" to be vectors where the first item is expected to be a keyword and the rest can be whatever, but a map works well.
I have an example that keeps track of the age of each "command/item/letter" in the "module/word"
They make a big deal about deterministic vs. stochastic but I just allow the rules to be functions and if it is a function I call it. So the function can do anything, predictable or unpredictable.
And if it wants to be context sensitive I have support for that as well by passing the current, previous, and next command to the rule function.
The result is a way to easily generate a ton of data that has fractal/simulation-like characteristics.
Now, what do you do with that data? You feed it to consuming functions that turn it into sequences of commands to drive things like turtle graphics or overtone music or laser cutters or whatever.
I'm working on a non-cartesian graphics system next, which will have a simplified abstraction traditionally known as a turtle from LOGO.
I think I'm gaining an understanding of why LOGO failed and how to do it right in Clojure/Script.
Well, failed to gain significant traction and failed by putting a ceiling on what could be done with the language.
And what they got right with turtle graphics, but failed to capitalize on (and nobody seems to have noticed).
So imagine the appeal of turtle graphics brought to a language like clj combined with powerful libraries for doing things like L-Systems in all its variations.
I'm picky so I'm still not happy with it but I am really happy that I've been able to keep it to less than 50 lines of code, more or less.