Code

C4 models allow us to visualize software architecture by decomposition in containers and components. Viewpoints are organized in hierarchical levels: Context Diagrams (Level 1) Container Diagrams (Level 2) Component Diagrams (Level 3) Code Diagrams (Level 4) C4-PlantUML offers a variety of macros and stereotypes that make modeling fun. An example in PlantUML: sample.puml @startuml !include <c4/C4_Context.puml> !include <c4/C4_Container.puml> left to right direction Person(user, "User") System_Ext(auth, "AuthService", "Provides authentication and authorization via OIDC") System_Boundary(zone1, "Some system boundary") { System(lb, "Load Balancer") System_Boundary(az, "App Cluster") { System(app, "App Servers") { Container(app1, "App1", "Docker", "Does stuff") Container(app2, "App1", "Docker", "Does stuff") ContainerDb(dbSess, "Session DB", "Redis") ContainerDb(db1, "RBMS 1", "AWS RDS Postgres") ContainerDb(db2, "RBMS 2", "AWS RDS Postgres") ' both app servers sync sessions via redis Rel(app1, dbSess, "Uses", "Sync Session") Rel(app2, dbSess, "Uses", "Sync Session") ' both app servers persist data in RDBMS Rel(app1, db1, "Uses", "Persist/query relational data") Rel(app2, db2, "Uses", "Persist/query relational data") } } } Rel(user, lb, "call") Rel(lb, app1, "delegate") Rel(lb, app2, "delegate") Rel(app1, auth, "Verify", "User auth") Rel(app2, auth, "Verify", "User auth") SHOW_FLOATING_LEGEND() @enduml ...

Goals Setup Prettier for different environments / IDEs Run Prettier via git hooks Install Prettier Install via npm npm install --save-dev --save-exact prettier Add empty configuration file echo {}> .prettierrc.json Create Prettier ignore file .prettierignore: # Ignore artifacts: build coverage Format all project files with Prettier: npx prettier --write . Git Hooks Adding the following lines to the project’s package-json makes ESLint and Prettier run before each commit: { "husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "**/*": "prettier --write --ignore-unknown" } } ...

Whitesource Configuration for GitLab Pipeline The following configuration derives values from predefined GitLab Variables whitesource.conf # Providing project information from GitLab CI wss_project_name="$CI_PROJECT_NAME" wss_project_version="$CI_JOB_ID" wss_project_tag="$CI_COMMIT_TAG" # Providing product information wss_product_name="The Product Name" wss_product_version="$POM_VERSION" # Analyze the Maven POM and its transitive dependencies only, no file-system check # Use this only if you don't have any extra checked in jar-files or stuff like that! fileSystemScan=false includes=pom.xml # Only scanning the Maven project resolveAllDependencies=false maven.resolveDependencies=true ...

For the most of us developers, generating Java source files is an occasionally happening task and we’re dealing with it e.g. when writing annotation processors, writing tools or interacting with meta-data files. JavaPoet is a nice library to simplify such tasks, offering an intuitive fluent-builder API to generate source files in no time. In the following tutorial I’d like to share a few examples by writing code generators with the help of this library. ...