This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (91)
- # announcements (1)
- # beginners (5)
- # boot (228)
- # cljs-dev (9)
- # cljsrn (12)
- # clojars (13)
- # clojure (175)
- # clojure-art (6)
- # clojure-russia (46)
- # clojurescript (35)
- # core-matrix (62)
- # cursive (10)
- # datomic (5)
- # hoplon (119)
- # ldnclj (11)
- # leiningen (7)
- # mount (3)
- # om (21)
- # reagent (2)
- # slack-help (1)
- # spacemacs (1)
@laforge49: https://github.com/hoplon/javelin/commit/da9fb7439021a94ef4c92fc956c8600005eae900 is kind of a bad practice. Those kind of things should be in your global gitignore, not on each project. See https://help.github.com/articles/ignoring-files/#create-a-global-gitignore
But one question. What happens if someone else writes those ide files to the repository. Will they not then overwrite my project files? Isn't it better to prevent everyone's ide files from being written to the common repository? With cursive growing in popularity, this becomes a growing issue.
@laforge49: that's a good question, I only used Cursive for a couple of weeks before going back to vim. In general those things would be caught on PRs before getting merged so I don't think that would be a big problem.
I converted the petrol examples (https://github.com/krisajenkins/petrol) to hoplon, they are an interesting pattern for applications inspired on Elm. The code is at https://github.com/hoplon/demos/tree/master/petrol
The advantage I see is that the ui has no need to know about the app structure, only publish messages.
So look at the multicounter example. There is no advantage on the small examples realy
whenever i've thought that a message bus was the thing i needed i've always regretted the decision later
The multicounter uses the counter2 ui as it was defined only forwarding messages to the component. The subcomponent don't need to know anything about the structure of the bigger component.
But those patterns are useful if you go to the one big atom church. They don't make sense if components have local state and are responsible for it.
I'm usually not a fan either but this pattern at least make it sane for building apps using it.
maybe it's a cljc thing, like some reason why the dot wouldn't work cross-platform or something?
Kris Jenkins is the one to thank for, I only did a conversion. Only needed to change 2 functions of the library to make it hoplon friendly.
Yeah, I like that a lot too. If elm had hoplon syntax including the way things can be combined it would be perfect. Static type checking is a powerful thing for big apps.
It always has trade offs but it's more useful as the app grows. Useful error messages are a win too, elm has the best ones ever, really amazing.
I would like to see what kind of code people put on space shuttles and rockets. And how they check if it does what it should.
program might crash or become faulty on one instance but it will just use the others then
I read something about nasa but to few details. There is a spec and there is translation to code. And they said its about it.
on a drillship there are humans interacting directly with massive dangerous computer controlled equipment
That should be interesting in the same way. Everything that cannot fail for one reason or another needs to have better processes at least.
to guarantee availability, so no single node can saturate the network and prevent other nodes from sending messages
Not quite sure of that, there is too much code to be written to take so long on it. But certainly slower than web apps 😉
the voyager spacecraft had a program on it that was almost an entire career for one dude, i think
wow, 40000 hours is something like 20 working years. Pretty impressive amount of time
yeah, and on weekends too and took no vacations it could be possible. I'm worst than useless working late, lots of bugs born this way.