Category Archives: Java/Java EE

JavaOne – 10 tips to become an awesome tech lead

Posted on by
2

“10 tips to become an awesome tech lead”

Speaker: Bart Blommaerts

For more blog posts from JavaOne, see the table of contents

Not one free seat in the room and long wait list line. [I wait listed and left the keynote 5 minutes early to ensure I got in]

Role of Tech Lead

  • Provide tech leadership
  • Protect team from interruptions
  • What new libraries/frameworks should we use? What are risks?
  • Coaching
  • Communication – bridge gap between devs an business

Do we need one

  • In ideal world, don’t need tech lead
  • Hard to do everything by consensus
  • Unlike the lego movie, everything is not always awesome
  • Business still needs point of contact
  • New people still need training

The ten tips

  1. Advocate for change – don’t want people to be afraid of prod, need to evolve. Try to make stupid processes better. OODE – observe/orient/decide/act
  2. Work through failure and success – prepare for failure, don’t finger point (“we”), take responsibility, learn from failure, problem if you are fixing the same bug twice – that is process failure. Celebrate success – sprint celebrations, feature complete, congratulate team/individuals
  3. Stay technical – write code, review code, tech vision (and get buy in; ideally with everyone contributing to it), evolution of code. Don’t forget about security/networking
  4. Time management – be available – spending time on tech design, talking to the business, project management (ex: help write user stories) and code
  5. Be a mentor for your team – facilitate discussion. Help team becomes stronger developers. Delegate. Optimize for the group/team
  6. Surround yourself with other tech leads – on a personal level, see what others do to get ideas and learn. On an organizational level, look at common org/architecture along with interoperability/dependencies
  7. Interviewing potental new team members – know your goals. For short term,, looking at tooling. For longer term, look at eagerness to learn. Don’t use stack overflow to find questions; pick things relevant to your project
  8. Embrace cultural differences – diversity, culture, family. Your users are different too.
  9. Estimating is hard – “Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.”. Planning poker. Uncertainty is normal. Add 20% for test/debug/polish/documentation/wtf moments.
  10. Interfacing with the outside world – want to be the go-to person, but not the single point of failure
  11. Faciliate an agile and awesome team

Other notes/tips

  • Not difficult for tech lead to make things worse
  • Need to experience same pain as everbody else on team – you are part of the team
  • Be realistic. Not possible to answer every question. Also, need to connect teammates to each other. Ok to request time to look into a question as long as you get back to them. Also ok to suggest pairing.
  • Not making a decision is worse than making the wrong decision becuase not doing any work
  • Interview style – comfort people (they are nervous; start with a siimple question like “what is the difference between an interface and abstract class in Java”), offer options, build on responses like “what is the difference between interfaces/abstract classes in Java 8”, show interest, bonus question
  • Offshoring – work gets done while sleeping, communication harder. Prepare work for remote teammates since they can’t talk directly to business. Harder to make everyone feel like part of team. ex do a night shift “most developers work better at night” [I am so non standard here!] Keep history ex: Slack

He commented about people working nights the last couple sprints to ensure success on the project. [That sounds completely against the sprint of sprints being sustainable]

My take: Nice to have a good tech soft skills talk. I noticed that Bart referred to “technical lead” as “he” whenever he used a pronoun. I wonder if it’s like that in his native language. Google translate says both tech lead and developer use “le” (are masculine) in French. This was more obvious at the beginning; he switched to “you” after a bit. And he said he/she later on.

JavaOne: JUnit 5 Features, Architecture and Extensibility

Posted on by
Reply

“JUnit 5 Features, Architecture and Extensibility”

Speaker: Steve Moyer, Stephen Seltzer & Niraja Ramesh
Deck on GitHub

For more blog posts from JavaOne, see the table of contents

This is “part 2” because last year they gave a session. It’s an expanded version of that talk now that JUnit 5 is done.

Rationale

  • Decouple test execution/reporting from test definition/provisioning
  • JUnit 8 features. ex: message nw last param and can be lambda
  • migration-support – JUnit 4 rules
  • junit-platform-console – to execute from command line; have to build full classpath

Principles

  • Prefer extension points over features
  • An extension point shoul be good at one thing
  • Should be hard to write tests that behave differently based on how run
  • Test should be easy to understand
  • Minimize dependencies; epecially third party

Features

  • Meta Annotations – compose annotations out of other annotations
  • Tags/filters
  • Dependency injection through params on constructors/methods
  • Default interface methods

Code examples (also on GitHub

  • Assertions – assertEquals(expected, actual, message)
  • Skip tests @Disabled
  • Lambdas – assertTrue(a, () -> message)
  • Grouped assertions – assertAll(message, () -> assertEquals(expected, actual, essage))
  • Exceptions – assertThrows
  • Assumptions assumeTrue, assumeFalse, assumingThat – he last one sets a scope (lambda) for the assumption and continues after that block regardless
  • Meta-annotations Create annotation with other annotation. Similarly can tag tests with annotations. Eclipse lets you specify filters in run config
  • Repeated tests – pass how many times to run along with what to display – can pass current repetition an tota reptitions to display name. Not for performance testing (other tools for that) but good for idempotence testing
  • Parameterized tests – can feed in CSVFileSource, CSVSource (CSV as strings), MethodSource. See docs for implicit conversions [didn’t mention value source :(]
  • Test templates – designed to be invoked multiple times and run like indepenendent test method. Parameterized tests are an implmentation of test templates
  • Lots of extension points and callbacks. Can programmatially decide whether to run tests.
  • ParameterResolvers – TestInfo (has display name, test class and test method), TestReporter (allows publising to output report) – can have JUnit pass as param to test
  • Callback order – BeforeAll, BeforeEach, BeforeTestExecution, Test, AfterTestExcution, AfterEach, AfterAll. Does parent class before child on Before*** and after child on After***
  • Dynamic tests – use @TestFactory – have display name and Executable interface
  • Grouped tests – Can use traditional for loop, assertAll or factory tests. Different output. Traditional for loop only ells you about first failure. With assertAll, get all failures but one faling test. With factory tests, you have a failing test for each faiure.

Future