Fork me on GitHub
#hoplon
<
2016-01-02
>
laforge4915:01:27

@micha Hope you like the change to Javelin. For some reason, I could not create a pull request using the github windows tool. Perhaps because I already have project write access--I'll need to check.

laforge4915:01:04

All I did was replace the first paragraph on lenses and added a reference. Easy enough to revert. simple_smile

laforge4915:01:45

Pull requests can only be built for a branch, it looks like: https://help.github.com/articles/creating-a-pull-request/

laforge4915:01:14

I'm thinking that for more extensive changes then I should just create a branch that can be merged in later. simple_smile

laforge4917:01:45

@micha If I go here, I get a brief description of each project: https://github.com/hoplon But if I go here, I get no descriptions of the demos: https://hoplon.github.io/demos/ My first thought is that we should be pulling the descriptions out of the build.boot files. But there are none! I'll note that project.clj carries a description, but boot.build does not. Is this a boot template issue? Or a deficiency of boot???

laforge4917:01:35

Perhaps we can just add a :description to boot.build. Would it work with https://github.com/boot-clj/boot/wiki/For-Cursive-Users

laforge4917:01:44

or would we need to update that?

laforge4917:01:04

In any case, it would then be easy to extract the description for each demo.

laforge4917:01:34

(though not so easy for me perhaps) πŸ˜„

laforge4917:01:28

In any case, I think it important to have a description of each demo on this page: https://hoplon.github.io/demos/

micha18:01:30

@laforge49: boot doesn't have any concept of "project"

micha18:01:44

it's just a library with functions you can use to build things if you want

laforge4918:01:57

@micha I tried putting :description in a build.boot file and everything looks ok. More to the point, the description is added to the project.clj file generated by "boot lein-generate"

micha18:01:58

if you're making a pom.xml there is a description field

micha18:01:32

yeah you can have a function in your build.boot that outputs any kind of data file of course

micha18:01:37

which is the way i would recommend

laforge4918:01:58

so why not add a description for each hoplon demo?

micha18:01:07

sure, got for it simple_smile

micha18:01:13

*go for it

laforge4918:01:13

Easy enough to extract then for the list of demos.

laforge4918:01:31

I'll write the descriptions then. πŸ˜„

laforge4918:01:09

And I'd be more than happy if you did the "easy" part of extracting the description for the web page

micha18:01:41

the demos index page probably needs work

laforge4918:01:48

though it is arguably a good project for me to work on perhaps.

micha18:01:58

i had some half baked system for generating that

micha18:01:08

github pages is a pain to work with

laforge4918:01:37

which is why I was thinking it better to put the description in the build.boot for each demo

micha18:01:52

i think instead of making that index html page we should just use the wiki or something and link to the demos

laforge4918:01:13

I like that a lot better.

laforge4918:01:23

Even I can do that.

micha18:01:27

basically we just remove the index page

laforge4918:01:32

Though I'd appreciate your review.

laforge4918:01:49

we create a wiki folder perhaps, for demos

laforge4918:01:10

sorry. overkill

laforge4918:01:19

there is already the readme for each project

laforge4918:01:26

just need a demos wiki page.

micha18:01:03

or the README for the demos repo itself

micha18:01:22

i could make a script that builds the main README with links to the individual demos

laforge4918:01:43

but I prefer the wiki for access control reasons

micha18:01:10

i'll make a quick little script and see how we like it

laforge4918:01:39

I'm heading for the pharmacy and will likely be off line all day after that. 😞

laforge4918:01:50

Need niquil so I can sleep at night

laforge4918:01:14

--last night was better, I only got up for an hour 3 times.

laforge4918:01:42

But I find running errands in nyc with a cold rather devistating

laforge4918:01:04

and have one on me!

micha18:01:34

maybe i will put some schnapps in my hot chocolate

laforge4918:01:13

maybe a bourbon would help with my cold. simple_smile

laforge4918:01:27

(nothing in the house, unfortunately.) πŸ˜„

laforge4918:01:49

@micha I just had a great idea for a project. Though likely you may have already thought of it. --Connect a javelin lens via castra and notify to a database lens. Wow!

laforge4918:01:43

Now your spreadsheet becomes distributed AND durable!

alandipert18:01:03

we have been intrigued by ideas like that, we call the durable cell "the stem cell"

alandipert18:01:13

as in, the cell from which all others are derived

laforge4919:01:10

I like the idea of connecting models with the underlying reality. Now you can have a value displayed on a page which reflects the current value in the database AND changing that value updates the database. Makes the display very "real". Virtual reality meshes with reality and all that.

micha19:01:50

i'm not such a fan of that usually

micha19:01:08

but maybe with lenses it makes sense

micha19:01:06

i've found that it's important to completely decouple the view over the state, that is to say the representation of the state, from the semantics for updating the state

micha19:01:28

usually in my experience the application state is not like a register where you fetch and store values

micha19:01:53

usually there are side effects involved and the view over the state that the application sees is only a small part of it

micha19:01:34

but i guess some aspects of it are like registers

micha19:01:28

i suppose what i mean to say is that it only makes sense for certain parts of the state

alandipert19:01:33

oh i forgot to share here, a recent revelation

alandipert19:01:39

the utility of viewing maps as tuples

alandipert19:01:52

about the tuples i say they're n-ary, but i mean n-place specifically

laforge4921:01:56

@micha You are right. The real value is the coupling of a cell in a client to a value in the database, especially when the app is in the browser. Much less so the value of coupling a view to the db contents. The exception, quite often, being maintenance. simple_smile