MicroProfile 1.4 and improving developer experience

[John Clingan]

With MicroProfile 1.3 nearly done (great job everyone!!), it's time to think a bit over the holidays about what we should do for MicroProfile 1.4.

An idea I brought up during the MicroProfile Live Hangout last week (December 12th) was to not focus on features, but to instead focus on how to educate developers on developing with MicroProfile. So, here is a bulleted list of ideas for MicroProfile 1.4:

• Address MicroProfile 1.3 backlog. No new specifications, but existing spec groups can finish off any work they could not fit into the MicroProfile 1.3 release.
• Developer guide. The guides we currently have are not content-rich enough for developers using MicroProfile.
  
• Examples. Small, discrete examples on how to use each major feature of each specification.
  
• Blogs/Articles. Continue writing articles on how to use the features.
  
• Videos. Live-coding videos on each technology.
  

Amelia had a good idea on creating a survey on how to improve the developer experience that would contribute to the above.

Any other ideas?

[Martijn Verburg]

The Conference sample app to be updated?

Cheers,
Martijn

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/63dbb938-dae1-4277-95f6-2f2f60ee3b78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John D. Ament]

For some reason, at one point I thought we were saying the next version is MP 2.0, to start to align to EE8 features?

I think we can work on some of these outside of a release cycle.  I do agree that solidifying some of the specs is important, but I'm also worried about the lag time between spec creation and spec implementation within the various runtimes.  Maybe this would give us time to align back to those implementations?

John

[Kevin Sutter]

+1 (alignment time)

[Kevin Sutter]

Also, this is one of the takeaways I took from JavaOne...  Expanding our Guides...  Draw developers into the fold...
https://groups.google.com/d/msg/microprofile/R36N5_NMwNU/Iorb20KqAgAJ

I've been wondering whether we could require a Guide as part of our component release process.  Of course, it couldn't be a pre-release requirement since we may not have an implementation yet.  But, we would require an Issue logged for creating a Guide specific to the component release.  And, whoever writes the Guide can pick their favorite implementation (or whatever one is available).  :-)

The other implementations could then expand on this Guide, providing their own unique instructions where they apply to their implementation.  So, then a single Guide could expand to 3, 4, or 5 versions that support each of the implementations.

Just an idea to discuss...

-- Kevin

[Emily Jiang]

+1 on writing guides!

The other idea we had from JavaOne is to provide some real case study to demonstrate the usage of MP programming models in the format of
A problem description
followed by using MP to achieve the goal

Why? What? How? Wow... approach will be great.

Emily

[Ivan St. Ivanov]

Hi everyone,

I'd like to comment on the "marketing" part of the initial mail in this thread:

• Developer guide. The guides we currently have are not content-rich enough for developers using MicroProfile.
  
• Examples. Small, discrete examples on how to use each major feature of each specification.
  
• Blogs/Articles. Continue writing articles on how to use the features.
  
• Videos. Live-coding videos on each technology.

We at Bulgarian JUG created a while ago the MicroProfile Hands-on-Lab: https://github.com/bgjug/microprofile-hol. It is still at a pre-1.0 version and focuses on the three Java EE specs in MicroProfile 1.0 and on building executable jar on the 4 founding platforms and running it. The Maven project produces a zip containing a step-by-step PDF guide and a few microservices that together form a "real-life project". It will be downloadable from our github page once we create the first tag (the infrastructure is already there). :)

To be honest, we didn't have the urge so far to continue working on it and to include the exciting new stuff from 1.1 on, as our HoL submissions were constantly rejected at conferences and we decided to devote our free time to other community activities. But after the call for marketing (I am referring back to the MicroProfile breakfast at JavaOne), we decided together with my co-author Dmitry Alexandrov to resurrect our project.

Our plan after polishing and completing 1.0 is to create a completely new lab in parallel to the existing one. Instead of piling up new chapters to HoL 1.0, we want our users who know what CDI, JAX-RS and JSON-P is to start directly from implementing the various microservice patterns coming with MP 1.2 (or maybe we can consider 1.3). We also want to somehow feature other implementations like Hammock, KumuluzEE and Fujitsu. What I want to do once we have the plan in our heads is to first write a blog on using a certain MP spec and only then add that to the lab.

To conclude, we are open to taking this discussion to another thread or even a hangout with those who are interested in contributing ideas or pull requests that will help us evolve the HoL.

Thanks,

Ivan

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/18531d54-8685-4752-ab80-ea0d2b4b24c7%40googlegroups.com.

[Kevin Sutter]

Ivan,
This sounds right in line with what we are thinking....  Demonstrate MicroProfile's features (individually or combined) with multiple implementations.  This would very much demonstrate the flexibility and power of the MicroProfile programming model.  I think many of us are wrapping up our efforts with this MP 1.3 release and then calling it a year...  But, kickstarting this activity in the new year sounds like a good idea.

Thanks, Kevin

[Mike Croft]

+1 for a developer guide and examples!

When I was putting my last presentation together, I took a look at some of the TCK tests for a good overview of the basic building blocks for specs like Fault Tolerance. We already have the microprofile-samples repository, might that be a good place to create these kinds of samples? IMO, the main work would be to have decent readme files since the samples are best kept as simple as possible.

[Guillermo González de Agüero]

Guides will be most than welcome! Also, I really miss a page with links to all the specs. Currently the most similar thing I find is the projects page (http://microprofile.io/projects) which lists all repositories (not just specs) and automatically renders the AsciiDoc content. A clear list of specs with links to html/pdf documents would be equally useful and easy to do.

Regards,

Guillermo González de Agüero

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/476d2766-1014-46a7-bfb6-422522cbb42c%40googlegroups.com.

[John Clingan]

I have some recommendations here:

• We all agree on document technology (AsciiDoc?)
• We all agree on a common template.
• Look and feel
• Common guide structure, but not over-defined and rigid.
• Agree on granularity. Options:
  
• End-to-End guide. All things specific to a specifications in a single guide
• HOW-TO. Pick a specific use case and solve it. Each spec can have multiple HOW-TOs. I prefer this option because it makes it easy for community members to contribute their own HOW-TOs as opposed to managing a large document.
• Both. Possible, but there will be some overlap and it will take more time. We all have spare time, right? LOL.

[Kevin Sutter]

John,
I created a skeletal 1.4 release in Eclipse for you...
https://projects.eclipse.org/projects/technology.microprofile/releases/1.4

I picked March 23rd as the release date since the Eclipse reviews are scheduled for the 1st and 3rd Wednesday of each month.  The 3rd Wednesday is March 21, gives you two days to do any final cleanup before doing formal release.  Note that everything needs to be ready for the review at least 7-10 days before the actual review and you need to request it via the link on the page.  Of course, let me know if you need any assistance with this process.

We should probably start creating Issues to help track the work required for 1.4...

Good luck, Kevin

[Mike Croft]

I really like these suggestions, John.

IMO, we should use this 1.4 cycle to refocus on the microprofile.io website as the "home page" for *users* of MicroProfile, just as the Wiki is the "home page" for *contributors* of MicroProfile.

If we take this approach, then we can create a Gitter chat room based on the microprofile/microprofile-site repo. There would be a problem with that since that is outside of Eclipse, but we could always create a new eclipse/microprofile-docs repository and create asciidoc + site.yaml in the same way that we handle specs currently.

It would be useful if someone from Tomitribe could comment on how easy/hard it would be to treat that one repo as a special case?

Alternatively, we could just document microprofile-samples better to satisfy John's "How to" use case, and better document the microprofile-conference app as an end-to-end guide. Adding a site.yaml to both would make them parsable by the current website, we would just need to highlight them properly so that it's obvious to visitors that that's where the documentation is.