Fork me on GitHub

Still set for a brief meeting about the interactive tutorial, and any other assorted topics in 40 minutes. Feel free to participate or watch. 🙂


So which part of the tutorial except aggregation and windowing would be most relevant to cqrs?


Perhaps the catalog section. That’s pretty fundamental


I’m really excited for this. It’s everything I always hoped we’d build as a community 🙂


I'll start playing with blueprint on the weekend and take any section once I get the hang of it


Cool. Let me know if there is anything i can do to assist 🙂


@colinhicks Nice work, I was having a slew of hangouts issues but I caught most of it. Currently busy this week but I hope to be able to knock out some of the tutorials after Friday.


Cool. Even if it’s not a whole section, the more examples we can build up in the better off we do. 🙂 Every contribution will help.


Weekend is probably my timeline too


What’s the reasoning behind dispatching off of keyword->component rather than symbol->component?


(Assuming we're talking about keywords in the section layouts ... ) That's a good point—I didn't explore the latter. I got enamored with the symmetry of blueprint component & blueprint layout versus keyword identifiers in catalog task & (e.g.) workflows.


Guys, i'm just starting in onyx and i am still not capable help to much in creating tutorials. I used the blueprint and learn onyx tutorials to starting my study been very good for me. For now im trying to use onyx-datomic plugin and learn about windows and triggers. So i allways update the source from blueprint and ready new tutorials, i can comment about news tutorials from the new onyx user perspective. For now i gonna try build a tutorial from my case.


@lellis Perfect! Thank you 😄


Using keyword -> component might be nice if we want to remote load a tutorial? Kind of like how Klipse can remote-load from a gist.


Dynamically rendering components from a gist won’t be difficult, but I’m not sure how we’d dynamically compose the component’s query back to the root.


The only reason I bring up the question about keyword/symbol component identifiers is because the tutorial layout looks so much like hiccup syntax already. I can appreciate the desire for symmetry there though. I don’t think its terribly important either way as long as the backing components are not tied to resolving keyword->component. I could see people wanting to use these components in devcards or their own projects, it would be nice if we could decouple our component resolution strategy from the component itself.


Mind if I create an issue to capture this? I'd like to give it some more thought.


Yea definitely worth some more consideration.


I don't think it blocks the tutorial-creation process at this stage, though, do you?


The use of modules is pretty interesting to split out the self-hosted stuff


@michaeldrogalis I remember you mentioning clojure.spec and namespacing all the catalog keywords, but I can't find usages of clojure.spec in any onyx-platform repository except empathy. Did I imagine?


Not ready to make the jump to 1.9-alpha yet since that would force all Onyx users to upgrade too