Fork me on GitHub
#off-topic
<
2016-12-02
>
kevin4213:12:22

I’ve just discovered this little neat tool to fake mouse and keyboard remotely http://www.semicomplete.com/projects/xdotool/

kevin4213:12:32

It can be handy when playing with a RPi

dominicm16:12:37

Is there something I'm missing about ragtime? I thought that was good, also migratus as used by the luminus project

greenhorse17:12:39

I just watched the "Spec-ulation Keynote" video and had a thought. What if each time library code changes - its namespace name would also change. So each new version of the namespace will have a unique namespace name. (for example: ns myproject.YYYYMMDD.HHMMSS). Then consumers of the library would :require a specific version of the namespace which is immutable and will never change. ( :require [myproject.20161122.221100 as myproject]). I think this should allow things like using different versions of the same library in one project side by side as they will be in different namespaces.

dpsutton17:12:00

honestly that sounds really gross

dpsutton17:12:37

like you update a small version bump of a library and you have to find every file where you use it and for most of them you append a new integer to the end of the import statement?

dpsutton17:12:05

and all you are doing is encoding which version you are using, which should be the information provided by one statement in your project.clj file where you say which version of the code you are using

greenhorse17:12:24

you don't have to update. you can continue using old version.

fellshard17:12:23

What you just stated is functionally equivalent to the semantic versioning he was speaking of. Allowing a tool to automatically increment and create a new namespace isn't managing change; it's just deferring it to some tool that can't determine whether that change is breaking or not. It's on us to be more disciplined and to use our tools to manage that change.

greenhorse18:12:06

But wouldn't this guarantee that no matter what happens to libraries - your code will never break.

fellshard18:12:01

... I think you missed the point of the talk.

fellshard18:12:39

It's not just about artifact binding, but usage and expectation binding. He discusses focusing on accretion and fixation, neither of which should cause code to break. In classic terms, loosening preconditions and strengthening post-conditions.

metametadata23:12:48

@dominicm what I like about Joplin is support for migrations written in pure Сlojure