Illegal Argument

Mark, along with co-host Greg's ongoing discussions and arguments relating to the Java/JVM and general development/language space with an Auckland and New Zealand focus.

178: Java 22 Released! And I Am The Technical Debt 03/25/2024

New Year, Old Year? What Year!?! 12/29/2023

176 - Better Late Than Never? 09/04/2023

175: 18 And Life... 08/21/2022

Episode 174: plz.review 07/19/2022

Episode 174: plz.review Reddit Post: Blog Post: YouTube Introduction Video: Website: Guests: Dylan Trotter, Matt Schweitz It's been a while since recording, and as it happens, just before organizing the next episode, full of “discussion” on the recent Java 18, and forth-coming Java 19 release, I came across an r/programming post from Dylan Trotter from Bit Complete about their new stacked code review tool for Github. After reading the post, linked blog post, and introductory YouTube video, I reached out to discuss the product, the problems with Github's default PR model, and code review in general. Contents 00:00:03.754 Introduction 00:01:07.236 Bit Complete History 00:02:24.492 What Makes A Good Code Review? 00:12:32.219 DORA (not the Explorer) 00:14:38.308 Bisecting Squashed Commits 00:18:51.617 The plz.review Solution 00:19:08.934 plz.review Stacks - Grouping PRs Together 00:21:36.969 plz.review Revisions: Force push solutions 00:25:37.590 plz.review Migration - Moving from Gerrit? 00:29:34.371 Gerrit and Github Integration 00:32:23.516 Compromising your workflow to fit Github PRs 00:39:41.700 Code Review as Mentorship / Education 00:41:26.759 Github: Social Coding brought code-review to mainstream 00:45:52.124 Long Lived Support Branches 00:50:03.479 How to signup for plx.review Overview Before we get into plz specifics - I assume both Dylan and Matt have some interesting takes on what makes a good review: What makes a good review? What constitutes good review "hygiene"? Mark: IMHO A review/commit/PR should ideally do one thing. What the "thing" may be intangible, but ideally: If you're going to reformat code, keep it in a commit separate from business logic changes. If you're updating dependencies, keep them separate from business logic changes, however do include code changes to ensure the build continues to build and pass tests. If a dependency update introduces breaking API changes, keep that dependency change along with the implementation for it. - The four DORA metrics are: Deployment frequency: How often a software team pushes changes to production Change lead time: The time it takes to get committed code to run in production Change failure rate: The share of incidents, rollbacks, and failures out of all deployments Time to restore service: The time it takes to restore service in production after an incident The first three metrics I can see being highly impacted by small changes, automated testing and CI integration. These all intersect with code reviews – having visibility that a proposed change actually compiles, passes tests, and doesn't introduce any new security issues before a co-worker even looks at the change speeds up the process. Stacked code reviews promote changes (with small being a subjective size), We've spoken on code formatters before on the show, keeping consistency for reviews is a good thing regardless of being automated or not. plz.review The project/platform appears to solve several issues we're facing with Gerrit, and our adoption of Azure Devops: Azure Devops is unable to pull from patch-sets, due to the private rev nature of Gerrit Writing custom Azure function(s) to listen to Gerrit events and manually trigger a Devops build is viable, but not ideal. The prospect of abandoning Gerrit and switching to Githubs force push and squash approach makes me cry, Coming from the Gerrit Code Review Tool it's great to find a stacked review tool for Github, having people getting in the habit of force pushing to remotes just promotes bad hygiene IMHO. Looking at the available docs, several interesting things come to mind: Comparison: Gerrit and - which I've used in the past for some open source work ( originally used GerritForge). Gerrit keeps all patch-sets - and lets you compare diffs between patch-sets, is that also mirrored within plz.review? I guess Github would only track to latest/amended PR. Looks like the plz command line generates its own form of Change-Id footer: plz-review-url which tracks revisions of a change linking to https://plz.review/review/NNNN - which doesn't appear to be name-spaced in any way (company or repo). Gerrit's UI is getting better, but still leaves a lot to be desired – I still wish improvements to commenting/UX were more of a focus. plz.review's UI also seems simple in design (not necessarily a bad thing), UI/UX design is hard in general, the requirements of a stack version control also seem to make it a tricky balance between fully featured, and clean….` Gerrit Migration – Given git patch-sets/comments are all in git refs, is there a migration strategy to expose them into plz.review/github? Is there a potential migration strategy? plz.review feels early in the development stage. Such things may not have been considered, or deemed out-of-scope for the system. Comparison: - Open Source CLI/web dashboard stacked review tool based on Git, designed to work with Github. - - (Change Log Podcast Interview). Automated bot responses - with CI/test results often being published back into Github PR's as validations for viable PR merges, do these get reflected in the plz UI, or even -2 rejections? Dealing with commits outside of plz.review - such as automated release commits that push direct to GH / potential conflict resolution (having access to Gerrit's local git repo has often been a godsend). What's the business model for plz - per repo charge? per organisation? per user? /episode/index/show/illegalargument/id/23786039

173: The Red Zone 02/17/2022

172: Separating The Release From The Build 11/15/2021

171: Breaking (up) The Build 03/19/2021

171: Breaking (up) The Build In an unprecedented show of activity - merely two weeks after the new years first episode (170) Mark and Greg are back, this time joined by Andres Almiray (Oracle) and Stephen Connolly (Cloudbees) to discuss all things build, modules, this weeks Java 16 release, and why Java programmers should take a look at the rust programming language. Hosts Greg Amer Guests Table of Contents 00:00:15 Intro 00:00:37 Guest Introductions 00:02:05 Java 16 Released! 00:02:47 Jenkins and JDK Versions 00:04:38 var changes = LIPSERVICE; 00:05:11 Improve your Java by learning Rust 00:07:31 Hey Bruno - It's NOT YAML! 00:10:22 Project Liliput 00:11:31 Java Turning 26 00:13:30 Java for CLIs? 00:16:47 Modules: Thought on The Java Platform Module System 00:18:12 Modules: Modules and Versioning 00:19:15 Modules: Semantic Versioning 00:22:19 Build: Hijacking The Maven Release Process 00:26:40 Explicit Merge Commits 00:29:16 Build: JDK Dependency (Lacking) In Maven 00:31:21 Kotlin Standard Library Versions 00:31:53 Libraries should avoid Guava 00:35:36 Jackson Version 3 Changes 00:39:10 Modules: The Lack Of Runtime Versioning In Modules 00:39:46 Modules: Agents And Module Systems 00:40:39 Run The Damn Tests Twice 00:46:00 Modules: Module Systems and Debugging 00:55:02 The Ecosystem Is More Than Code 00:55:46 Build: The Hinderance of IDEs 00:56:47 Build: Mixins In Maven 01:02:18 Build: The Perfect POM is with a BOM 01:07:17 Build: Custom Lifecycles as Mixins 01:10:09 Build: Gradle is Surprises and Deathtraps 01:11:31 Build: Maven Consumer POM and POM 4.0.0 01:14:16 Build: Project Dependency Trees Proposal 01:23:28 Build: Maven 4 and 5 Releases 01:26:49 Build: Plugin Phases and Execution Order 01:33:05 Build: Interim Hacks and Abstractions Considered Harmful 01:39:33 The Problem with Preview Features News - OpenJDK proposal to reduce the Java object header by half or more would lower memory and CPU usage on all Java workloads. Pull Requests merging instanceof Pattern matching and many other new . and with it - JDK11 baseline Links and the versioning conflicts that may arise for Build Health Problems with sorting, tidying poms Build / life cycle order / Mixins (YouTube Video) Plugin Execution & Property Ordering Tests Module Systems Java Platform Module System / Jigsaw - Including an excellent video demonstration of Layrry in action with JavaFX. OSGi Runtime Dependencies (build is only half the picture) /episode/index/show/illegalargument/id/18389687