unomi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shu...@apache.org>
Subject Re: Some articles talking about Unomi
Date Thu, 15 Nov 2018 08:28:51 GMT
On Wed, Nov 14, 2018 at 12:44 PM Otavio Rodrigues Machado <
omachado@thoughtworks.com> wrote:

> Hi, Serge!
>
> Thanks for reading it! :)
>
> On your topics:
>
> *I am curious about the lacks in documentation you mention in the article.
> Did you see the new manual that's now available on the site ? Could you
> maybe suggest improvements that would have helped you ? Michael is also
> working on a tutorial which I think would probably help onboard more
> people.*
> I actually didn't see the manual! Do you have the link for it? I did a
> quick search in the webpage but still couldn't find it.
>

You can find the manual here :
http://unomi.apache.org/manual/1_3_x/index.html
The lastest version (in line with the master source code is here) :
http://unomi.apache.org/manual/latest/index.html

There are some minor issues with the links in the documentation, I still
need to fix that.


> I feel that the documentation is really good for covering *business* and
> *bootstrapping*. The Tweet example was awesome, but in general I did not
> see a lot of information about:
> - How to implement segments;
>

Yes I think more concrete examples would be good. There is a basic example
here but it could be expanded :
http://unomi.apache.org/manual/latest/index.html#_predefined_segments


> - How to do write custom conditions (i still don't know what is the
> ESQLBuilder, for example);
>

Yes you are right, this also need a more complete example, although custom
conditions are (in my experience) rarely needed. You can already do a lot
with the existing conditions especially when building new conditions just
using JSON and using scripting.


> - What are the built-in conditions, rules, segments and actions that can
> be used from the start;
>

Good point, there is no list of these.


> - How to write complex rules (apart from "if a property exists")
>

Actually for both segments and rules the condition system is the same, so
explaining it once for both would be better. All we have right now is the :
http://unomi.apache.org/manual/latest/index.html#_predefined_rules


> - What is the core entry of unomi's logic. (It took me one whole day to
> understand that wab, for example, was just parsing data to send to
> EventService)
>

Noted. That could be very useful to newcomers indeed.


> - What are the core modules
>

Not sure what you mean by that ?


> - Examples in general (example of requests for the rest api endpoints,
> example of )
>

In the Running Unomi section we have some examples, but maybe there are not
properly seperated in the document :
http://unomi.apache.org/manual/latest/index.html#_running_unomi


>
> Regarding concepts, I feel that my knowledge is still lacking for the
> concepts of *Item*, *Scope*, *Source*, *Target*. I have been looking to
> the entry points of Unomi, so I don't really know what those last two are
> used for – I just assumed that they were there for specific-application
> purposes, if needed.
>

Item and scopes are quickly described here :
http://unomi.apache.org/manual/latest/index.html#_items_and_types

Source and targets are described in the Event part here :
http://unomi.apache.org/manual/latest/index.html#_events


>
> This is what I can think of, but whenever I remember of something I can
> start writing it down to send you.
>

Sure that's great. And if you feel like contributing to the documentation
please don't hesitate ! This can be done in many ways, because I want to
make it easy for people to contribute. You could either send a pull request
or just a mail in this mailing list with the suggested modifications, I
would be glad to integrate them.


>
> *I do want to react to the performance and scalability. At Jahia we test
> Unomi with data sets of over 5 million profiles and have target for 95%
> response times below 100ms with a three node cluster. This is usually
> achieveable with reasonable hardware provided the storage is using SSDs as
> recommended by ElasticSearch.*
> On performance and scalability, I will write an edit. I still have to test
> it out with better machines – I am actually waiting for one to do that as I
> write this e-mail. I did see that you have performance tests there, so
> that's awesome.
> Have you thought about using RX to improve that?
>

Yes I thought about that but currently the thread system is not (yet) a
bottleneck. Rule execution and writing to ElasticSearch are the two
currently known bottlenecks. For both of these I have improvement ideas but
you can already offset some of this by using more nodes (Unomi and
ElasticSearch nodes).


> *If you'd like we could link to your articles from the website (in the
> resources section for example ?)*
> If you think it's worth it, I would be honored. :)
> I intend to keep working with Unomi, and will for sure continue to write
> about it.
>

Yes I definitely think it's worth it, because Unomi can benefit from having
independant articles at this stage, this helps validate the viability of
the project and its growing community.


>
> *Also in the hub of articles I see some upcoming ones. Are you aware that
> we are working on a GraphQL version of the API ? *
> I haven't! But now I will surely take a look at it!
>

The branch is here :
https://github.com/apache/incubator-unomi/tree/UNOMI-180-CXS-GRAPHQLAPI
and there is an associated ticket here :
https://issues.apache.org/jira/browse/UNOMI-180
As you can see we are working on a specification related to this too, the
link is in the JIRA ticket.


> I am also working in a Message queue entry. It's in a separated project,
> but if you would like, we could discuss about creating a agnostic one to
> exist as a module in the main source code.
>

Very cool, this is definitely something that could be interesting for Unomi
I believe. Let me know how I can help !


>
> *If you have questions for your upcoming articles please don't hesitate to
> reach out. You can also email me directly if you like, but of course the
> mailing list is a better place to make sure the community grows (as you've
> clearly identified it should). Also we are currently in the process of
> graduating to a top level project and I'm hoping we can do this by the end
> of the year.*
> Those are great news! Congrats!
> I will for sure reach out whenever I have questions.
>
> Thanks again for going through what I have been writing. That's for sure a
> warm welcome for me in the community. :)
>

You're welcome, its part of growing the community to treat it well :)

Best regards,
  Serge...


>>

Mime
View raw message