Clojure Con: Day 1 Sessions Recap and Highlights

• Lunch programs

https://twitter.com/timbaldridge?lang=en

• batch operations

go -> loop -> when-some -> if -> when | recur

• transducers are a recommended key starting point

xf comp cat partition-all

• pipeline
• AutoCompleter example with params:query

The OM.next example indicates how the framework is responsible for the async parts of the problem. Changes to the query will cause dependent UI to rerender.

• Pedestal Interceptors

http://pedestal.io/reference/interceptors

https://twitter.com/ebethme?lang=en

https://twitter.com/deepbluelambda?lang=en

• Example application is around the targeting of offers for abandoned
• Amazon API gateway
• https://aws.amazon.com/api-gateway/details/

https://github.com/awkay

Look at the amount of time that is actually spent in doing UI spot checking, database seeding, unit testing, etc. that contributes to the quality of the product.

There's a culture of fear and expertise that permeates the time spent testing vs. actually developing the application.

What is the coverage actually provided by the testing that is done manually vs. automated.

Use a Haskell-style approach of side-effecting and non-side-effection components of the application.

zThis also the approach used to effectively test the "functional" or utility methods.

What are the trade-offs between less and more code and the relationship with local and globale confidence.

Example: testing the C implementation of sin (approx 800)

• input values that consider the implementation
• use generative testing and create a new implementation that may be slow but is a faithful Taylor expansion of PI
• use precision in language
• https://www.youtube.com/watch?v=zi0rHwfiX1Q&index=28&list=PLZdCLR02grLp__wRg5OTavVj4wefg69hM
• Generative testing: https://purelyfunctional.tv/issues/clojure-gazette-104/
• Mocking the data: https://github.com/untangled-web/untangled-spec
• Is inference a justified approach when looking at deeply embedded library calls
• Using words to describe and think about the problem is likely the best use of time about testing. When finding that the problem is hard to describe or test it comes back to complexity of the design.
• Example: testing macros: https://clojure.org/guides/spec#_macros

• look at the way that the API calls are segmented out when performing refactoring
• look at the trade-off with time, cost, readabiltiy, and input parameters
• https://github.com/aiba/yourkit-clojure-repl
• https://docs.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html
• production data can potentially lead to optimization based on structures that could be exploited
• https://github.com/hugoduncan/criterium
• Consider bundline in New Relic early
• https://github.com/TheClimateCorporation/clj-newrelic

• UI data tree to DOM
• teleport provides a set of quick steps to move into a particular state
• cookies and headers modelled in the test system
• the PR issue: teleports created with each commit and branches are up to date with master (not just conflict free)

• http://tcrawley.org/j9clj
• http://github.com/tobias/clojure-java-9/issues

• use gnerative testing to increase the space associated with the test cover
• test check starts by removing characters
• (->Javascriptify

The other Sussman course that should be parallel is

https://groups.csail.mit.edu/mac/users/gjs/6.945/

This uses multi-methods for multiplying different interfaces

• https://en.wikipedia.org/wiki/Automatic_differentiation
• See SICP https://mitpress.mit.edu/sicp/full-text/sicp/book/node39.html
• Automatic differentiation
• Sybolic differentiation
• Simplification
• Functional Differential Geometry

See also

• http://www.neilvandyke.org/racket/sicp/
• https://www.cs.rochester.edu/~gildea/guile-scmutils/
• http://www.neilvandyke.org/racket/sicp/

• https://github.com/littleredcomputer/sicmutils

https://twitter.com/ra

• inspection into the system

• https://www.speedrun.com/

• Racket with Rosette

https://emina.github.io/rosette/rosette-guide/index.html