Analytics for aerogear.org website
by Paul Wright
Hi,
Can someone reach out to me regarding analytics for https://aerogear.org/
We're currently trying to figure out how to transition to new site and
docs, and would like some data to drive decisions around redirects and
archiving,
thanks,
Paul
--
Paul Wright
Mobile Docs (github: finp)
6 years, 10 months
Location of Docs
by Paul Wright
Hi,
At a meeting a few weeks ago, we decided not to centralize all the docs for
mobile.next, because:
* keep docs closer to code
* keep docs and code versioned together
* allow devs update docs in same repo as they are working
We also decided not to create sidecar repos, eg a mobile-<service>-docs
repo.
With that in mind, I thought that docs for push would end up in:
https://github.com/aerogear/aerogear-unifiedpush-server
and docs for android sdk would end up in:
https://github.com/aerogear/aerogear-android-sdk
but that was before I discovered that the following is the nearest thing to
a 'metrics' repo that would be suitable for /docs:
https://github.com/aerogearcatalog/metrics-apb
However, I don't think switching org is a good experience for anyone (user
or contributor), so I'm wondering if anyone has a good idea where to docs
should live (relative to the code), eg:
* service and sdk docs live the apb repos
* service docs in apb repos, and sdk docs in 'code' repo
* something else
thanks,
Paul
--
Paul Wright
Senior Technical Writer
Red Hat, Waterford, Ireland
gitlab: finp
6 years, 10 months
Push modules (was Re: UPS: Admin UI)
by Matthias Wessendorf
here is the proposal:
https://github.com/aerogear/proposals/pull/21
On Mon, Feb 5, 2018 at 8:05 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> Hi, Dave
>
> thanks for the feedback
>
> On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti(a)redhat.com> wrote:
>
>> For RHMAP 3/4, the Studio was originally part of a single jar/war
>> (millicore). It did have a jsp for delivering the index.html (which
>> wrote a bunch of inline javascript)
>>
>> The studio was then decoupled from the war file as a separate war
>> (fh-studio). However, it still had an index.jsp, but called back to
>> the 'core' to get some of the info needed for that.
>>
>> This was eventually refactored into a node.js express app (fh-ngui)
>> and deployed completely separately. It still made calls back to the
>> core to get some config/user info.
>>
>> The main benefit I found was the UI could be progressed at a faster
>> pace as the local development tooling could be tailored better. (just
>> run the UI server & hook up to an existing core somewhere)
>> However, it introduced overhead with the addition of a new deployable
>> component.
>>
>
> that's also some of the points. We already have the development moved over
> to a different repo.
> We currently just stick it's JAR (which might be silly) into the WAR.
>
>
>>
>> This was all in a pre-containers world, but it was migrated to a
>> container world (on openshift).
>> We never went as far as nginx serving static content, but I could see
>> that as a logical progression.
>> It would probably mean a smaller footprint overall.
>>
>
> cool. It's something I will include in the proposal (not done any
> testings).
>
>
> Currently I look removing some good parts of the WAR file for the push
> delivery itself.
>
> current approach, which I do like so far, is having each "network" run as
> a java process, that wires the "send bits" (e.g. for iOS) togehter via
> messaging (kafka).
> Here is a metrics screenshot:
> https://user-images.githubusercontent.com/157646/
> 35808591-9393ec6c-0a86-11e8-9b6f-f138fe0a5691.png
>
> code is located here:
> https://github.com/matzew/aerogear-unifiedpush-server/tree/
> 8d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-
> agent/src/main/java/org/aerogear/push/apns
>
> It's borrowing some concenpts/code from core UPS. but is really no http
> server - just a standard Main, which has a kafka consumer, plugged via ENVs.
>
> I currently deploy to Openshift using the fabric8-maven-plugin (fmp), that
> generates all all (docker file, k8s/oc yamls).
>
> I will do the same for FCM.
>
> Once that all is done, we have no "sending" code in the UPS, and we can
> move than the UPS itself to WF-Swarm, for a migration to a simpler
> develipment/deployment model (and perhaps some more modules in the longer
> run)
>
> Proposing:
> * fcm-sender.jar (in container)
> * apns-sender.jar (in container)
> * UPS move to Swarm
> * UI in nginx
>
>
>
>>
>> On 30 January 2018 at 19:40, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>> > Hi,
>> >
>> > right now, we have the static resources of the admin ui build to a JAR
>> file
>> > and a "node tgz". Currently, in the community, we use the bundled JAR
>> and
>> > deployed to the UPS WAR file. So far, so good
>> >
>> > For our modularization I was thinking at different options:
>> >
>> > * WildFly Swarm w/ just static (WAR) resources
>> > * Node.js/Express app
>> > * Ngnix container, just serviing the content
>> >
>> > I've tested 1) I was wondering if we might - for some better resource
>> > utilization might just go w/ Ngnix, and deploy the static resources of
>> the
>> > admin UI to there?
>> >
>> > How do other think about breaking the UPS down to different
>> technologies and
>> > aspects?
>> >
>> > -Matthias
>> >
>> > [1] https://github.com/aerogear/unifiedpush-admin-ui
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > github: https://github.com/matzew
>> > twitter: http://twitter.com/mwessendorf
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Aerogear" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to aerogear+unsubscribe(a)googlegroups.com.
>> > To post to this group, send email to aerogear(a)googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq
>> -VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> David Martin
>> Red Hat Mobile
>> Twitter: @irldavem
>> IRC: @irldavem (#aerogear)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Aerogear" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to aerogear+unsubscribe(a)googlegroups.com.
>> To post to this group, send email to aerogear(a)googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/aerogear/CADvBQ45yhH_-%2BZ2gKsU-agjv2ucngsgUgo66-dQ7Mdyo
>> MuDinw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
6 years, 10 months
Adding a dashboard to Grafana
by Paul Wright
//taking cover already as I'm about to ask people to name things
You don't add a table to Postgres, you add a table to a database,
You don't Firefox a web site.
and in general, you don't add <item> to <product>, you add <item> to
<function or component>
so, I don't like the phrase 'adding a dashboard to Grafana'
I suppose we might 'add a dashboard to the Grafana instance', but that
seems wordy,
And everyone is busy, so I'm going to say either:
a) add a dashboard to the Grafana instance
b) add a dashboard to <AeroGear Reports>
Note: I've spoken to a few ppl about this, and they're looking at me
funny, but I'd like to point out that this is what I'm basing my view on
the fact that a dashboard is not supposed to be a mere visualization:
https://en.wikipedia.org/wiki/Dashboard_(business)
Paul
(waiting for all the counter examples)
--
Paul Wright
Mobile Docs (github: finp)
6 years, 10 months
UPS: Admin UI
by Matthias Wessendorf
Hi,
right now, we have the static resources of the admin ui build to a JAR file
and a "node tgz". Currently, in the community, we use the bundled JAR and
deployed to the UPS WAR file. So far, so good
For our modularization I was thinking at different options:
* WildFly Swarm w/ just static (WAR) resources
* Node.js/Express app
* Ngnix container, just serviing the content
I've tested 1) I was wondering if we might - for some better resource
utilization might just go w/ Ngnix, and deploy the static resources of the
admin UI to there?
How do other think about breaking the UPS down to different technologies
and aspects?
-Matthias
[1] https://github.com/aerogear/unifiedpush-admin-ui
--
Matthias Wessendorf
github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
6 years, 10 months
SDK API doc
by Paul Wright
Hi,
There is existing tooling to generate API reference doc for Android and
iOS. I'm thinking we should use that to generate comprehensive API doc
for both platforms (and later for Cordova).
I believe this gives the best experience to the <platform> developer, on
the basis that, at any one time, they developer is working on a single
platform (and typically a colleague is developing the 'other' platform).
The disadvantages of this approach include the fact that the appearance
of generic docs/android/ios will all be different, but we can put enough
navigation into the html to allow users enter and exit this reference
without too much pain.
However there is also a requirement to show the cross platform nature of
mobile-next, to demonstrate the generic nature of a particular call. I'd
like to address this, not in the 'full' API docs, but in examples of
typical use cases which might look like
getSyncClient().list("tasks");
For more information see <link to android ref docs>
syncClient.listWithDataId("tasks")
For more information see <link to ios ref docs>
WDYT?
--
Paul Wright
Mobile Docs (github: finp)
6 years, 10 months
