opendaylight developer experience 2.0

74
Developer Experience 2.0 September 27, 2006 @ ODL Summit Seattle Michael Vorburger.ch, Red Hat

Upload: michael-vorburger

Post on 16-Apr-2017

245 views

Category:

Technology


2 download

TRANSCRIPT

Page 1: OpenDaylight Developer Experience 2.0

Developer Experience 2.0September 27, 2006 @ ODL Summit SeattleMichael Vorburger.ch, Red Hat

Page 2: OpenDaylight Developer Experience 2.0

This OpenDaylight SDK presentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

$ historyThe first half of this presentation is a summary of the “OpenDaylight has Oomph!” presentation from the Mini European Summit on June 21st 2016 in Berlin (talk video, slides, demo, src), repeated on a TWS WebEx on July 18th.

The second half is new content based on work since then.

#helpwanted = YOUR contributions most welcome!

Page 3: OpenDaylight Developer Experience 2.0

Not quite a 5’ Ignite talk (20 @ 15s)… but close - cram in double slides in ½ the time! ;)

Page 4: OpenDaylight Developer Experience 2.0

1.Eclipse Setup (10’) Why? What? How?

2.Code Quality (5’) Checkstyle etc.

3.Dev Build/Deploy (5’) HOT?

4.End2End Tests (5’) Incl. @Inject DIJoin my 3-4pm tomorrow!

This OpenDaylight SDK presentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Page 5: OpenDaylight Developer Experience 2.0

1. Eclipse Setupbased on the Oomph Eclipse Installer

Page 6: OpenDaylight Developer Experience 2.0
Page 7: OpenDaylight Developer Experience 2.0

And you just wanted to contribute your very first open source bug fix today, not get a black belt in IDE-ology!

Page 8: OpenDaylight Developer Experience 2.0

2. What?

2,278,082 Downloads

Page 9: OpenDaylight Developer Experience 2.0
Page 10: OpenDaylight Developer Experience 2.0
Page 13: OpenDaylight Developer Experience 2.0
Page 14: OpenDaylight Developer Experience 2.0

What’s in it for you?

• git clone, import

• Working Set (dyn)

• MAGIC (m2e)

• 20+ Plugins

• 20+ Preferences

• YANG Editor

• Goodies

Page 15: OpenDaylight Developer Experience 2.0
Page 16: OpenDaylight Developer Experience 2.0

Eclipse Tips

• Don’t disable Auto Build

• No separate workspaces

• Red? Alt-F5 (mvn), not clean

• Close Projects / Working Sets

Raise questions on dev list with prefix "[eclipse]", or ping me IRC/email me, if needed.

Page 17: OpenDaylight Developer Experience 2.0

Goodies

• EGit

• EGerrit

• Docker & Vagrant; Terminal

• FindBugs, PMD, EclEmma, YEdit, InfiniTest, AnyEdit, ...

Page 18: OpenDaylight Developer Experience 2.0

EGit

Page 19: OpenDaylight Developer Experience 2.0

Gerritby EGit

• Push to Gerrit

• Fetch from Gerrit

Page 20: OpenDaylight Developer Experience 2.0

EGerrit

Page 21: OpenDaylight Developer Experience 2.0
Page 22: OpenDaylight Developer Experience 2.0
Page 23: OpenDaylight Developer Experience 2.0

3. How?

Page 24: OpenDaylight Developer Experience 2.0
Page 25: OpenDaylight Developer Experience 2.0
Page 26: OpenDaylight Developer Experience 2.0

2. Code Quality, in IDEBug prevention (incl. security); uniformity lowers friction

Page 27: OpenDaylight Developer Experience 2.0

What do these have in common?“Please change import statements to be alphabetically ordered”“Move comment to previous line, as this will trigger a Sonar warning”“java.util.Optional preferred over com.google.common.base.Optional”“Field logger should be called LOG”...

Page 28: OpenDaylight Developer Experience 2.0

What do these have in common?“Please change import statements to be alphabetically ordered”“Move comment to previous line, as this will trigger a Sonar warning”“java.util.Optional preferred over com.google.common.base.Optional”“Field logger should be called LOG”...

These kind of code review comments on changes proposed via Gerrit are all a waste of not just 1 but of 2 people’s productive time!

Developer should have already been informed about anything like this right there while typing it! (Same principle for post merge Sonar.)

Page 29: OpenDaylight Developer Experience 2.0

Why Checkstyle/FindBugs/Sonar?A.Formatting Conventions

1.Shared Code

needs

2. Common Style

B. Find real bugs!

FindBugs’ UC_USELESS_OBJECTe.g. ovsdb c/42345.

Checkstyle’s System.out (e.g. netvirt c/43973), and Exception handling.

Page 30: OpenDaylight Developer Experience 2.0

Code Quality must be in-IDE• Eclipse Plugins for Checkstyle autom. installed!• Even more importantly, autom. m2e pre-configured!! • Sonar same (Eclipse plugin, config; manually activate)

• My efforts to drive reasonable sensible common shared set of rules in odl-parent for all of ODL.

Page 31: OpenDaylight Developer Experience 2.0
Page 32: OpenDaylight Developer Experience 2.0

Format & Import (Ctrl-Shift-F & O)Wrong lexicographical order for '...' import. Should be before '...' ?

Just Source > Organize Imports, it works “as expected”, because it’s

correctly configured to “do the right thing” for ODL Checkstyle.

Source > Format is aligned as well.

Page 33: OpenDaylight Developer Experience 2.0

How-to move existing code to Checkstyle enforcement? Gradually:1.Bundle by bundle, never entire ODL project (git repo) in one go!2.Clean all violations and violationSeverity=error (in same change)3.If a lot of violations, then several Gerrits: split pure cosmetic

(formatting) from impactful (e.g. exception handling changes)

#helpwanted - your projects?Above based on Gerrit change review experiences in mdsal with Dimension Data’s Brinda Jana, and some work in netvirt by me.

#helpwanted from more projects

Checkstyle - YOUR Plan

Page 34: OpenDaylight Developer Experience 2.0
Page 35: OpenDaylight Developer Experience 2.0

ODL Checkstyle++#helpwanted@see https://wiki.opendaylight.org/view/EvolvingCheckstyle, and:

1. Contribute controller slf4j logger checks to sevntu-checkstyle! (Contact me)2. AvoidHidingCauseExceptionCheck & EitherLogOrThrowCheck (c/43331)3. Upgrade Checkstyle version (incl. Eclipse plugin in eclipse-setup)4. HiddenField, HideUtilityClassConstructor, InnerAssignment (c/41305)5. FinalClass, HideUtilityClassConstructor (c/43324)6. ThrowsCount (c/43329), TrailingComment (c/41084), 7. VisibilityModifier (c/43330)

Page 36: OpenDaylight Developer Experience 2.0

3. Local Build, DeployBug prevention (incl. security); uniformity lowers friction

Page 37: OpenDaylight Developer Experience 2.0
Page 38: OpenDaylight Developer Experience 2.0

-Pq Quick Build

1. mvn [-o] clean install

7:41 min

2. mvn [-o] -Pq install

1:16 minTimings from ovsdb, as an example.

Page 39: OpenDaylight Developer Experience 2.0

-Pqmvn -Pq install skips:

• Tests compilation• Unit tests running• Karaf features testing• Integration tests running• Coverage instrumentation

(Jacoco)

• FindBugs analysis• Checkstyle analysis• JavaDoc generation• Source JAR building• Maven site building• Invoker, Enforcer

https://git.opendaylight.org/gerrit/#/c/40245/

Page 40: OpenDaylight Developer Experience 2.0

Deploy changed bundles to Karafmvn -o -Pq \ -DaddInstallRepositoryPath=$KARAF/system install [Eclipse: Shift-Alt-X-M]

dev:restarthttps://git.opendaylight.org/gerrit/#/c/40520/

Page 41: OpenDaylight Developer Experience 2.0

HOT Deploy changed bundles to Karaf

bundle:watch *Fixed ODL CSS Config handleChangedClass() Code Gen. [Bug 2855, c/40514/, c/40950] …... but in bundles migrated to OSGi Blueprint this is broken again :-(#helpwanted, e.g. Aries BP upgrade and/or debug ClassCastException

Page 42: OpenDaylight Developer Experience 2.0

BUT...

How often do you need to (hot) re-deploy the ODL code you’re working on, into a full networking environment?

Q: Are you live debugging a sneaky corner case, or developing? (New feature or functional extensions or technical refactoring of existing features.)

Are you practicing Test Driven Development (TDD) ?Test-first, really??

Page 43: OpenDaylight Developer Experience 2.0

4. Testingand Dependency Injection (DI)

Page 44: OpenDaylight Developer Experience 2.0

Kinds of Tests in ODL#helpwanted

• J/Unit: Internal classes, Mockito’ing dependencies (standalone Java)

• Integration: ODL Features, (Java OSGi Pax Exam)

• CSIT: ODL User Features, black box, networking system test (Robot suites)

• End-to-end (e2e) “API” Test• Cover functionality of 1 bundle• API, not int. implementation• Stub required ext. Services• Assert outcome on system• Wire BP @Inject w. Guice

• netvirt.aclservice

Page 45: OpenDaylight Developer Experience 2.0

Highly readable! Very Important for tests as literal API documentation.

Runs FAST & easy to debug!

Page 46: OpenDaylight Developer Experience 2.0
Page 47: OpenDaylight Developer Experience 2.0

This JUnit ComparisonFailure diff view is NOT Eclipse specific; works in IntelliJ (et al) too. (But not -currently- in CLI.)

https://github.com/vorburger/xtendbeans

Page 49: OpenDaylight Developer Experience 2.0

Anti Patterns for well testable code

• Don’t write static method in anything but the most trivial helper classes.

• Don’t use the public static YourThing getInstance() singleton pattern either.

• Do write small focused utility classes (without any static)

• Do use Inversion of Control (IoC) [Fowler]: wire objects by injecting implementation by DI (BP/Guice)

Page 50: OpenDaylight Developer Experience 2.0

Anti Patterns for well written tests

• Use Mockito... sparingly.(mock Optional?! c/45815)

• Tests that have more Mockito set up lines than other code:

• Testing too many internals?• Testing a class that’s too big?

• PowerMock? No… (At least not for typical functional code.)

PowerMock’s “power”: Test internals of badly designed code. In ODL, better to just refactor what you’re testing.

Page 51: OpenDaylight Developer Experience 2.0

BTW: Google Truth

Use Google Truth assertThat() instead of JUnit assert* or Hamcrest’s assertThat => more readable source, better IDE auto completion, and clearer failure message:

assertThat(some.isInit).named("isInit").isTrue();

http://google.github.io/truth/

Page 52: OpenDaylight Developer Experience 2.0
Page 53: OpenDaylight Developer Experience 2.0

Dependency Injection (DI) in ODLODL CSS Config => OSGi Blueprint XML (BP) => BP @Inject AnnotationsLess error prone than XML, AND enables us to re-use std. @Inject wiring metadata in e2e tests w.o. BP but e.g. with Google Guice.Manually wire few OSGi services.

Wiring duplication?Possible to use e.g. Guice at RT and not just Test, instead of BP? And use opportunity for on-demand instead Proxy services?

https://github.com/vorburger/osgi-services-di POC TBD...

Page 54: OpenDaylight Developer Experience 2.0

class AclServiceModule extends GuiceModule {

@Override protected void configureBindings() {

① bind(AclServiceManager.class) .to(AclServiceManagerImpl.class);

② bind(AclInterfaceStateListener.class);

Page 55: OpenDaylight Developer Experience 2.0

class AclServiceTestModule …… ① bind(DataBroker.class) .toInstance(DataBrokerTestModule.dataBroker());

② bind(AclClusterUtil.class).toInstance(() -> true);

③ private AclserviceConfig aclServiceConfig() { aclServiceConfig = mock(AclserviceConfig.class); Mockito.when( aclServiceConfig.getSecurityGroupMode()) .thenReturn(SecurityGroupMode.Stateful);

Page 56: OpenDaylight Developer Experience 2.0
Page 57: OpenDaylight Developer Experience 2.0

BACKUP SLIDESNot used in the 30’ presentation (too much)

Page 58: OpenDaylight Developer Experience 2.0

This OpenDaylight SDK presentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

$ whoamiMichael Vorburger.ch@vorburger

Page 59: OpenDaylight Developer Experience 2.0

What NeXT ?• Bndtools? The OSGi IDE:

• Instant bundle JAR builder• Semantic Versioning, in IDE...• Launchers for lightweight in-

container FAST OSGi integration testing (Karaf?)

• bnd.bnd pom.xml (mvn?)⇐bnd-based; ODL already uses, via maven-bundle-plugin.

• Writing e2e “API” Tests• DI in OSGi with Guice?• Join my 3-4pm tomorrow!• #helpwanted

• Code Quality (post CS):• FindBugs! #helpwanted• Null analysis?

Page 60: OpenDaylight Developer Experience 2.0

1.Why?

Page 61: OpenDaylight Developer Experience 2.0

1.Why?

Help - I still have Red X's! (i.e. Eclipse compile errors)“Eclipse is no longer able to compile OpenDayLight. The reason is three

maven plugins which are used by OpenDayLight but are not integrated

into Eclipse: maven-plugin-plugin, karaf-maven-plugin and maven-

antrun-plugin. This means you will always have Eclipse compile errors in

the project (this could go to up to 100000 errors).

You can use Eclipse for editing easily but to compile the project you

need to open a terminal window and do the compilation (...)”

Page 62: OpenDaylight Developer Experience 2.0
Page 63: OpenDaylight Developer Experience 2.0

YANG IDE• Builder• Folding• Validation• Doc Hover• Formatting• Highlighting

https://github.com/xored/yang-ide/wiki/Features

• Code Completion• Comment Toggle• Navigation (F3)• Templates• Outline

Page 64: OpenDaylight Developer Experience 2.0
Page 65: OpenDaylight Developer Experience 2.0
Page 66: OpenDaylight Developer Experience 2.0
Page 67: OpenDaylight Developer Experience 2.0
Page 68: OpenDaylight Developer Experience 2.0
Page 69: OpenDaylight Developer Experience 2.0

Sonar• Checkstyle VS Sonar? Checks have some overlap (inconsistencies)• Sonar does not run for Gerrit check builds (could & should it?)

• Sonar in-IDE, same config as on sonar.opendaylight.com:

Page 70: OpenDaylight Developer Experience 2.0
Page 71: OpenDaylight Developer Experience 2.0
Page 72: OpenDaylight Developer Experience 2.0
Page 73: OpenDaylight Developer Experience 2.0
Page 74: OpenDaylight Developer Experience 2.0

Contribute!Eclipse Setup Models project is FLOSS.Like everything else in OpenDaylight.Now more easily than ever before:You can contribute too!