[feedhenry-dev] Dogfooding for Developer Experience

[John Frizelle]

I'm not really sure it makes that much of a difference.

Typically, almost all development work is done locally - i.e. outside of
the studio.

The real interactions (and problems) with the product come after an app has
been released as people are then fairly well locked into using the studio
for management, monitoring, upgrades, debugging problems etc...

So, if we really want to dogfood our product, we need to get something
deployed and then go through the pain of trying to manage it through the
platform...


--
John Frizelle
Platform Architect, Red Hat Mobile
Consulting Engineering

mobile: *+353 87 290 1644 <//+353872901644>*
twitter:* @johnfriz*
skype: *john_frizelle*
mail: *jfrizell at redhat.com <jfrizell at redhat.com>*




On 10 November 2016 at 09:15, Matthias Wessendorf <mwessend at redhat.com>
wrote:

>
>
> On Wed, Nov 9, 2016 at 7:06 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>> Y'all,
>>
>> Wojciech and I had a quick call to flesh out the discussion we were
>> having on IRC about having a dogfooding exercise to better understand and
>> discover what pain points developers have.
>>
>> As far as Jiraisms go, we have a few things to figure out before we can
>> make a proper Epic out of it.  Once we do, however, I hope that we can get
>> things ready to start coding relatively quickly.
>>
>> 1) Do we want to greenfield an application or port an existing open
>> source application to the platform?  Greenfielding works great for learning
>> specific parts of the platform (ex Auth) or answering certain questions
>> (how do I get sync to do X, Y ,Z), but porting an existing application
>> gives us the opportunity to see how our platform's assumptions mesh with
>> the practices developers are currently using.
>>
>
> I think we should to greenfield, as that might be a bit more fun. So if we
> figure out certain parts of the platform that are not fun to use, it's good
> feedback for improving. I think greenfield works a bit better here, because
> you are a bit more flexible on ideas and concepts
>
>
> @porting:
> A bit off-topic; But: Currently I am mentoring a student from Waterford.
> He works on a Node.js / Microservices version of AeroDoc (+adding
> Keycloak). At a later stage this might be even ported to an RHMAP template.
> So this might be related. bringing in existing code to the platform
>
>
>
>>
>> 2) Do we want to focus on native (Windows + iOS + Android) or Cordova
>> clients?  Cordova apps will give us a better experience of challenges our
>> current users have, but because there are so few native users in comparison
>> a native focus may yield things which have been overlooked.
>>
>
> Hrm, not sure: both have benefits: native and cordova
>
>
>
>>
>> 3) I'm sure that more will come from this so feel free to ask and answer
>> your own questions here.
>>
>> Let's discuss in this thread today and Thursday and we can review it in
>> our meeting Friday.
>>
>> Summers
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>
>
> --
> Project lead AeroGear.org
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20161110/80cb2fe6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20161110/80cb2fe6/attachment.png>