Bore da

@dominicm @glenjamin that's going to be more than annoying in early stages of development when Spec's are fluid. Going to break that lovely REPL based flow. Probably not a big problem in more mature code bases when changes to Spec should be accretions anyway (according to the "Word of Hickey"). Does this just mean you explore data using the REPL and add Spec when it's more stable, will that mean reloading Spec's registry becomes less important?

Morning.

morning

Very interesting article on abstractions and how important it is to see them at different levels and interact with them....made me realise in a deeper way why I think Clojure is the best language I've found so far for exploring problems. http://worrydream.com/LadderOfAbstraction/

Also provides another slant on the static vs dynamic typing argument.

and is a reason why I disagreed with @krisajenkins about the detail of the approach on how he explored his problem space with data modelling. This article talks about exploring 3 dimensions simultaneously (time [or behaviour over time], data, structure [code])

certianly looks very good...

hrm, so it looks like a system built on c.t.n for reloading specs would be doable

It's my morning for posting interesting articles. Here's another one relevant to why I found learning Clojure hard...and rewarding. https://hbr.org/2016/11/why-the-problem-with-learning-is-unlearning

after unloading the old namespaces but before loading the new ones, you’d have to (swap! clojure.spec/registry-ref and remove namespaced keywords which match

@glenjamin so definitely possible then

well, it depends on what exactly the ^:private metadata does

but iirc it only stops it being imported, not being accessed fully-qualified

yeah I'm not sure but I think I remember being able to poke at private def's in test namespaces.

haha nice picture

morning

@glenjamin @#'some.ns/some-private-var does let you get at ^:private defs

that’s the one

feels a bit like the reflection hack in Java

morning

blimey, didn't see how much chat my spec snarking caused!

Anyone tried to understand Clojure internals - compiler and all that stuff? Reading Elixir internals == pleasure, reading Clojure internals == nightmare

there was a talk at euroclojure a couple of years ago on that very topic, Finding Monsters in the Clojure Compiler, something like that

https://vimeo.com/100518965 ? Yeah, some beasts in there.

it was a jolly good talk to 🙂

That talk was given in front of Rich (who also made the first comment). Still shivering...

Saved...to be watched later

@agile_geek I agree with your assessment about early stages of spec vs late stages. Might be a problem if you delete a spec in a large codebase, and start building new stuff — without realising that some specs still point to the deleted one! But this workflow is perhaps not one that spec intends to resolve.

Apart from @pupeno, anyone done isomorphic Reagent app? I'm looking into this now and wondered what the issues and tradeoffs are? For example, rendering server-side using node.js works but is it possible to run an nREPL and connect into the node process?

@agile_geek we've got an isomorphic reagent app

ah, but are you meaning cljs backend, rather than just code-sharing between cljs and clj ?

Yeah we share code in cljc files

We need server side rendering for SEO

and performance

Having a performance gain is hard unless you cache the results.

@mccraigmccraig how do you run the reagent app on the server?

@pupeno we don't - we just do some code-sharing between the front and back ends

@agile_geek i don't remember a lot, but I'd be surprised if you can't get the repl going.

@agile_geek happy to sit down with you and see if I can help.

We are due for a catch up anyway.

Performance issue is only really initial load so shouldn't be that hard - SEO is the killer. Despite Google claiming they can index client side rendering we get very little indexed

@mccraigmccraig what @agile_geek is talking about is prerendering the app on the server.

@pupeno did you end up using node or Nashorn?

yeah, i know now @pupeno 🙂

Yeah, I've heard from other makers of an SPA that Google is not really indexing them.

@agile_geek: no, Nashorn doesn't implement xmlhttprequest

If you have a non Ajax SPA, it could work. But who does that anyway?

If you're lazy, you can do http://prerender.io

Depending on the app, it may not be worth the bother of fiddling with js engines.

@dominicm I'm all for being lazy!

prerender may save you some work then!

that looks pretty neat thanks dominicm 🙂

you can still do it on nashorn if you wanted

you’d need to swap out the HTTP lib at a slightly higher layer

that’s the approach i’ve done with a NodeJS/React app

API compatible HTTP lib running in the browser and server

i’ve done plenty of server rendering with JS and React, calling React.renderToString is the easy bit, it’s deciding how to do data fetching that’s tricky

if your component’s data requirements can be processed fairly statically (ie. without rendering) then it’s not too bad

i can imagine that, should i really need to, for my re-frame app i could initialise the app-db statically for server-side rendering

that’s fine if you’re ok with 1 node process = 1 request at a time

otherwise you’d need some sort of isolation between them

@agile_geek are you joining the hangout today?

Too busy

@jr0cket I did decline the invite

we have http://style.com representation

Fine

FINE....

I don't represent Style and I'm working on different stuff from Abby. Got too much to do

#clojure-uk: Style insider information