Fedora developer portal - proof of concept

Nick Coghlan ncoghlan at redhat.com
Mon Jul 27 04:41:40 UTC 2015


On 07/24/2015 07:16 PM, Adam Samalik wrote:
> Hi Nick,
> 
> thanks! 
> 
> What I'm still missing in the current prototype is the "problem to be solved" starting point - as you pointed out at the env-and-stacks meeting. For example: I want to develop a web application. The site would give me options like Django, Flask, Ruby on Rails, PHP, Jekyll,... Or even better, something more precise like deciding the type of the web app: an application with backend and database, a static site, blog or a wiki page? The tech-specific overview would show up afterwards. Suitable tools and deployment option would show up as well. What do you think?

I think it probably makes sense to focus on http://devassistant.org/ and
https://dapi.devassistant.org/ as the entry points to the Fedora
developer experience. We may want to pick out particular assistants and
highlight them (especially if we design the Fedora DA package to come
with some assistants pre-installed), but I think it makes sense to push
the "comprehensive" side of the story further upstream, and have
developers.fedoraproject.org present a more filtered view, just as the
main Fedora repos represent a filtered view of the upstream software
repositories.

My rationale for that is that DA provides an abstraction layer over
various mundane technical details - if you're using a well-maintained DA
Assistant to automate setting up a particular kind of project, then your
own practices can automatically adapt as recommendations change. If
folks want to learn more about the details of a recommendation, they can
dig into the implementation of the relevant assistant, but if they don't
want to care, they don't have to.

The DA folks are also actively working on offering good support for the
"Container Tools" workflow coming out of Project Atomic - that's a
Vagrant+containers based approach designed to be cross-platform for
development purposes and cross-distro for both development and
deployment, so adopting it for web service development means folks are
automatically lowering the barriers to entry to contributing to and
deploying their project. That workflow also actively encourages folks to
clearly separate their unit testing from their behavioural testing.

Given a default assumption that folks are willing to use DevAssistant
(either through the GUI or through the CLI), then the following kinds of
questions could help guide site users to appropriate assistants:

* I want to build a web application, where do I start?
* I want to build a command line application, where do I start?
* I want to build a desktop GUI application, where do I start?
* I want to build a mobile application, where do I start?
* I want to work with the Raspberry Pi, where do I start?
* I want to work with Arduino devices, where do I start?
* I want to work with other embedded devices, where do I start?
* I want to provide online documentation for my project, where do I start?
* I want to collaborate effectively with others on my project, where do
I start?

That last one wouldn't be a pointer to any DA Assistants, but rather a
pointer to resources like choosealicence.com, and a review of some of
the available project hosting options (most notably GitLab, GitHub,
BitBucket and FedoraHosted)

Regards,
Nick.

P.S. A note regarding the Raspberry Pi: I think this is a good example
of a case where cross-distro development support is important, as we'd
like to make it easy for folks to develop for the Raspberry Pi on Fedora
while targeting both the default Raspbian image and the Fedora Pi remix,
rather than only supporting developing for the latter.

-- 
Nick Coghlan
Fedora Environments & Stacks
Red Hat Developer Experience, Brisbane

Software Development Workflow Designer & Process Architect


More information about the env-and-stacks mailing list