The document discusses the future of development tools across various categories such as programming languages, IDEs, source control, testing, and collaboration tools. It envisions tools that better understand code semantics, support modern paradigms, provide recommendations, visualize data and threads, integrate testing into documentation, and focus on semantic differences in code reviews. Overall, the document presents an optimistic vision of tools that make development more productive by understanding user intent and automating more tasks.

2. The Final Frontier
Martijn Verburg (@karianna)
www.jclarity.com - @jclarity

3. My Background
• Martijn Verburg (@karianna)
– CEO at jClarity
– Run Adopt a JSR & Adopt OpenJDK programs
– Speaker, Author, Java Champion
– aka "The Diabolical Developer"
• As a former CTO…
– Have seen *lots* of tools
• As a CEO…
– Part time coder, tools make or break my day

4. The Frontiers
1. Programming Languages & Libraries
2.IDEs
3. Source Control
4. Build and Deployment Tools
5. Testing and Code Analysis Tools
6. Performance Tools
7. Collaboration
8. Businesses
9. IoT

5. 1. Programming Languages & Libraries

6. Language Evolution
• Design Patterns
– which evolve into…
• Libraries
– which evolve into….
• Programming Languages!

7. State of Languages & Libraries
• Programming Languages still suck
– We have to execute very low level instructions
• Rarely does source code convey intent
– Partly our fault
• Functional / Reactive / Parallell / Asynch
– Are %*!@ killing us
• Libraries are too coarse grained

8. What if Languages and Libraries…
• Made us work with ASTs, not source code
– bit.ly/codeinast - Paul Phillips
• Provided the build tools for themselves
– No splintering of the build ecosystem
– e.g. go build
• Were micro modularised
– Java and Jigsaw will help for Java/JVM folks
– Classloader hell? Use JRebel!

9. The last programming language?

10. 2. IDEs

11. IDEs of the past

12. State of IDEs today
• Beginning to understand semantics
– e.g. Netbeans RESTFul services section
• Marginal improvements
– e.g. Netbeans native Maven support
• They don’t support modern paradigms
– Reactive, Asynchronous, Multi-threaded etc

13. State of the art?

14. What if your IDE…
• Behaved like Google docs
– e.g. Multiple collaborators on a file
• Recommended libraries
– From peer reviewed repositories
• Crowd sourced good code
– From peer review OSS projects
• Had a REPL for Java

15. What if your IDE…
• Had spotlight search for documentation
– Across languages!
• Advised you on data structures
– Asked for requirements and picked
• Advised you on common algorithms
– Breath, Depth, big O characteristics
• Advised you on resource usage

16. Could he come back?

17. What if your IDE…
• Had networked linked debugging
– Have a colleague mirror your debug session!
• Had comments next to your code
– e.g. bit.ly/sidecomments
• Converted source code to language X
– e.g. Groovy tro Java 8

18. What if your IDE…
• Helped you name things properly
– e.g. ’company_person to employee’
• Had an Single Responsibility Checker
– And the other SOLID principles
• Recommended a functional approach
– Netbeans did this for me the other day!

19. What if your IDE…
• Created dummy data for you
– For tests and debugging
• Had a visual design tool for developers
– Didn’t try to be perfect
– DOES tell you if you’ve committed a design sin
• Visualised threading / streams with data
– bit.ly/javaconcurrent - Victor Grazi
– bit.ly/reactive_explained - André Staltz

20. What if IDEs visualised streams..

21. What if IDEs visualised streams..
var multiClickStream = clickStream
.buffer(function() {
return clickStream.throttle(250);
})
.map(function(list) { return list.length; })
.filter(function(x) { return x >= 2; });

22. What if IDEs visualised streams

23. Inspiration from Lighttable

24. 3. Source Control

25. Distributed taking over

26. What if your source control…
• Warned you when you’re being stupid
– e.g. Merging one branch into another
• Had sensible names for commands
– NOT git commit
• Checked formatting from the CL
• Had semantic Binary diff…
– git-scm.com/docs/git-difftool

27. 4. Build and Deployment Tools

28. Along came Ant

29. Sigh

30. What if your build tool…
• Warned out about security breaches
– e.g. 3rd party lib X is vulnerable
• Built a patch against all branches
– Before manual code review
– Think Patch Queue
• Encouraged you to do the right thing
– But allowed you to be bad when needed

31. The final solution?

32. Deployment - Sorta done

33. What if your deployment tool…
• Was *truly* descriptive
• Wasn’t written in Ruby
• Knew what it had done before
– Chef/Puppet both leave dirty marks
• Guided developers on Ops tasks
– “IPTable? WAT?”

34. We still face configuration hell

35. 5. Test and Code A nalysis Tools

36. We’re pretty much done here
• JUnit, TestNG, Spock, Cucumber,
– Karma
• X Mocking libraries
• Arquillian for Java EE
• Findbugs, PMD, Coverity, Checkstyle
– Threadsafe….

37. However, what if testing tools
• Checked for out of data comments?
– Karma
• Had executable documentation
– ASCIIDoc? JavaDoc?
• Arquillian for Java EE
• Findbugs, PMD, Coverity, Checkstyle
– Threadsafe….

38. 6. Performance Tools

39. State of the Art today

40. XRebel - Early warning in dev?

41. jClarity Censum - Analysis over raw data

42. jClarity Censum - Analysis over raw data

43. jClarity Illuminate - Analysis via Machine
Learning

44. What if your performance tool…
• Live profiled without impact
– This needs managed runtime support
– bit.ly/chronicle-queue - Peter Lawrey
• Moved beyond profiling?
– We’re working on it ;-)
• Load tested with crowd sourced data
• Was predictive or even self healing?

45. 7. Collaboration

46. Remote work - 2015

47. Remote work - 2020?

48. Diversity

49. What if code review tools…
• Focused on semantic differences
– e.g. API breaking changes
– Bughawk - Richard Warburton & John Oliver
• Applied styling that suited the viewer
• Had a visual representation of data
• Had static analysis alongside the code

50. 8. Businesses

51. What if businesses…
• Allocated smaller budgets, frequently
• Asked for smaller, useful services
– Allowed users to use those first
• THEN decide what they really want

52. 9. IoT

53. IoT
• Fragmented market
– Is Java the glue that will bind it?
• Hardware emulators
– How do you test?
• BIG data
• Security modelling

54. You’re probably doomed

55. A reminder…

57. Acknowledgements
• Images
– gotstartrek.tumblr.com
– Gary Bernhart
– André Staltz
– docs.cs.byu.edu
• People
– friends@jclarity.com
– Victor Grazi, Mike Barker, Kirk Pepperdine
– Bernd Eckendes, Hardy Jonck, Chris Newland
– Peter Hilton, Ricahrd Warburton, Trisha Gee
– Twitter

58. The Future of Performance Analysis
www.jclarity.com - @jclarity
Martijn Verburg (@karianna)