Improve headers consistency, extract common fragments, fix some links…

… and visual issues.
JonathanGiles · Jan 9, 2024 · f9df079 · f9df079
1 parent 6e29d91
commit f9df079
Show file tree

Hide file tree

Showing 14 changed files with 66 additions and 131 deletions.
diff --git a/src/main/java/net/jonathangiles/www/pages/PostsPage.java b/src/main/java/net/jonathangiles/www/pages/PostsPage.java
@@ -35,7 +35,7 @@ public PostsPage(String slug, Set<Post> allPosts, boolean includeDesktopLinks) {
         sortedYears.addAll(postsPerYear.keySet());
 
         for (Integer year : sortedYears) {
-            allPostsHtml.append("<h3>").append(year).append("</h3>");
+            allPostsHtml.append("<h2>").append(year).append("</h2>");
             postsPerYear.get(year).forEach(post -> {
                 String path = post.getRelativePath();//.getParent().toString();
 

diff --git a/src/main/resources/www/pages/index.html b/src/main/resources/www/pages/index.html
@@ -5,7 +5,7 @@
 ${include header}
 <body class="page page-index">
     ${include hero}
-    <div class="container-fluid px-2">
+    <div class="container-fluid">
         <div class="row" style="min-height: 25px;"></div>
 
         <div class="row">

diff --git a/src/main/resources/www/pages/java-api-design-best-practices.html b/src/main/resources/www/pages/java-api-design-best-practices.html
@@ -2,15 +2,7 @@
 slug: /java-api-design-best-practices
 title: Java API Design Best Practices
 -->
-${include header}
-<body class="page">
-    ${include hero}
-    <div id="content" class="site-content container-fluid px-2">
-        <div id="primary" class="">
-            <main id="main" class="site-main" role="main">
-                <article class="hentry">
-                    <div class="page-content">
-                        <h2>Java API Design Best Practices</h2>
+${include page_top}
                         <p>The presentations below were presented in 2018, and were presented before I wrote the <a href="/jbp/index.html">Java Best Practices</a> site. For the latest guidance, you should head over there.</p>
 
                         <h3>Documentation</h3>

diff --git a/src/main/resources/www/pages/java-api-design-best-practices/index.md b/src/main/resources/www/pages/java-api-design-best-practices/index.md
@@ -13,31 +13,31 @@ You're in luck - you can [watch (or review the slides from) some of my presentat
 
 ## Best Practices for Java Developers
 
-- [JBP-1](/jbp/jbp-1.html): Use BOMs whenever available
-- [JBP-2](/jbp/jbp-2.html): Minimize dependencies
-- [JBP-3](/jbp/jbp-3.html): Don’t float dependency versions
-- [JBP-4](/jbp/jbp-4.html): Keep dependencies up to date
-- [JBP-5](/jbp/jbp-5.html): Make use of logging APIs
-- [JBP-6](/jbp/jbp-6.html): Configure build plugins
-- [JBP-7](/jbp/jbp-7.html): Use the latest Java Long-Term Support release
-- [JBP-8](/jbp/jbp-8.html): A little copying is better than a new dependency
+JBP-1: [Use BOMs whenever available](/jbp/jbp-1.html)\
+JBP-2: [Minimize dependencies](/jbp/jbp-2.html)\
+JBP-3: [Don’t float dependency versions](/jbp/jbp-3.html)\
+JBP-4: [Keep dependencies up to date](/jbp/jbp-4.html)\
+JBP-5: [Make use of logging APIs](/jbp/jbp-5.html)\
+JBP-6: [Configure build plugins](/jbp/jbp-6.html)\
+JBP-7: [Use the latest Java Long-Term Support release](/jbp/jbp-7.html)\
+JBP-8: [A little copying is better than a new dependency](/jbp/jbp-8.html)\
 
 ## Best Practices for Java Library Developers
 
-- [JLBP-1](/jbp/jlbp-1.html): Characteristics of good API
-- [JLBP-2](/jbp/jlbp-2.html): Embrace modules
-- [JLBP-3](/jbp/jlbp-3.html): Release to Maven Central
-- [JLBP-4](/jbp/jlbp-4.html): Publish BOMs for multi-module projects
-- [JLBP-5](/jbp/jlbp-5.html): Use semantic versioning
-- [JLBP-6](/jbp/jlbp-6.html): Resist breaking changes
-- [JLBP-7](/jbp/jlbp-7.html): Minimize API visibility
-- [JLBP-8](/jbp/jlbp-8.html): Minimize API
-- [JLBP-9](/jbp/jlbp-9.html): Design for extensibility (Draft)
-- [JLBP-10](/jbp/jlbp-10.html): Avoid shading dependencies (Draft)
-- [JLBP-11](/jbp/jlbp-11.html): Write great documentation
-- [JLBP-12](/jbp/jlbp-12.html): The importance of consistency (Draft)
-- [JLBP-13](/jbp/jlbp-13.html): Eat your own dog food
-- [JLBP-14](/jbp/jlbp-14.html): Document your deprecation policy
-- [JLBP-15](/jbp/jlbp-15.html): Don’t return null
-- [JLBP-16](/jbp/jlbp-16.html): Beware of boxing
-- [JLBP-17](/jbp/jlbp-17.html): Understand functional interfaces
+JLBP-1: [Characteristics of good API](/jbp/jlbp-1.html)\
+JLBP-2: [Embrace modules](/jbp/jlbp-2.html)\
+JLBP-3: [Release to Maven Central](/jbp/jlbp-3.html)\
+JLBP-4: [Publish BOMs for multi-module projects](/jbp/jlbp-4.html)\
+JLBP-5: [Use semantic versioning](/jbp/jlbp-5.html)\
+JLBP-6: [Resist breaking changes](/jbp/jlbp-6.html)\
+JLBP-7: [Minimize API visibility](/jbp/jlbp-7.html)\
+JLBP-8: [Minimize API](/jbp/jlbp-8.html)\
+JLBP-9: [Design for extensibility (Draft)](/jbp/jlbp-9.html)\
+JLBP-10: [Avoid shading dependencies (Draft)](/jbp/jlbp-10.html)\
+JLBP-11: [Write great documentation](/jbp/jlbp-11.html)\
+JLBP-12: [The importance of consistency (Draft)](/jbp/jlbp-12.html)\
+JLBP-13: [Eat your own dog food](/jbp/jlbp-13.html)\
+JLBP-14: [Document your deprecation policy](/jbp/jlbp-14.html)\
+JLBP-15: [Don’t return null](/jbp/jlbp-15.html)\
+JLBP-16: [Beware of boxing](/jbp/jlbp-16.html)\
+JLBP-17: [Understand functional interfaces](/jbp/jlbp-17.html)
diff --git a/...w/pages/java-api-design-best-practices/java-library-best-practices/jlbp-0006.md b/...w/pages/java-api-design-best-practices/java-library-best-practices/jlbp-0006.md
@@ -29,4 +29,4 @@ Fortunately, we do have tools on our side to keep us honest and aware of breakin
 
 The other kind of breaking change that we need to be very careful of is changes in behaviour. For example, if the `foo()` method is documented to always return `42`, and users begin to depend on this behaviour, it would be very unwise to change it to instead return `0` in a future release. The obvious solution to prevent this from happening is to introduce good quality unit tests to validate expected behaviour, and to ensure this does not change unexpectedly between releases.
 
-As mentioned in [JBP-6](/jbp/jbp-6), we should make sure to introduce code coverage tooling such as JaCoCo to validate that we are writing tests that cover these critical behavioural aspects of our code. Reading the reports generated by tools such as JaCoCo, we can very quickly identify code paths that may not be getting enough test coverage, and writing tests for these paths can help prevent accidental behavioural breaking changes.
+As mentioned in [JBP-6](/jbp/jbp-6.html), we should make sure to introduce code coverage tooling such as JaCoCo to validate that we are writing tests that cover these critical behavioural aspects of our code. Reading the reports generated by tools such as JaCoCo, we can very quickly identify code paths that may not be getting enough test coverage, and writing tests for these paths can help prevent accidental behavioural breaking changes.
diff --git a/src/main/resources/www/pages/media.html b/src/main/resources/www/pages/media.html
@@ -2,15 +2,7 @@
 slug: /media
 title: Media
 -->
-${include header}
-<body class="page">
-    ${include hero}
-    <div id="content" class="site-content container-fluid px-2">
-        <div id="primary" class="">
-            <main id="main" class="site-main" role="main">
-                <article class="hentry">
-                    <div class="page-content">
-                        <h2>Media</h2>
+${include page_top}
                         <div class="epyt-gallery" data-currpage="1" id="epyt_gallery_35745"><div class="epyt-video-wrapper">
                             <iframe id="_ytid_97260" width="688" height="387" data-origwidth="688" data-origheight="387" src="https://www.youtube.com/embed/l6qDwN4L0Fw?enablejsapi=1&autoplay=0&cc_load_policy=0&iv_load_policy=1&loop=0&modestbranding=0&rel=1&fs=1&playsinline=0&autohide=2&theme=dark&color=red&controls=1&" class="__youtube_prefs__ no-lazyload" title="YouTube player" data-epytgalleryid="epyt_gallery_35745" allow="autoplay; encrypted-media" allowfullscreen data-no-lazy="1" data-skipgform_ajax_framebjll=""></iframe>
                         </div>

diff --git a/src/main/resources/www/pages/presentations.html b/src/main/resources/www/pages/presentations.html
@@ -2,19 +2,11 @@
 slug: /presentations
 title: Presentations
 -->
-${include header}
-<body class="page">
-    ${include hero}
-    <div id="content" class="site-content container-fluid px-2">
-        <div id="primary" class="">
-            <main id="main" class="site-main" role="main">
-                <article class="hentry">
-                    <div class="featured-image">
-                        <img width="1410" height="939" src="/images/jonathan-devoxx.png" />
-                    </div>
-                    <div class="page-content">
-                        <h2>Presentations</h2>
+${include page_top}
                         <p>Over the years I&#8217;ve given many presentations all around the world, from the US to Europe, and India to Japan. I love interacting with like-minded developers, and I have been recognised as a &#8216;JavaOne Rockstar&#8217; for my popular presentations at JavaOne. Unfortunately I&#8217;ve never kept records of these presentations, but I&#8217;ve searched Google and my file system to link to as many as I can on this page. I hope they are helpful!</p>
+                        <div class="featured-image">
+                            <img width="1410" height="939" src="/images/jonathan-devoxx.png" />
+                        </div>
                         <hr />
                         <h3>2018</h3>
                         <p>In 2018 I presented the &#8216;<a href="java-api-design-best-practices.html">Java API Design Best Practices</a>&#8216; presentation at a number of conferences, so I have created a separate page to capture the various slide decks and recordings.</p>

diff --git a/src/main/resources/www/pages/projects.html b/src/main/resources/www/pages/projects.html
@@ -1,13 +1,9 @@
-${include header}
-<body class="page">
 
-    ${include hero}
-    <div id="content" class="site-content container-fluid px-2">
-        <div id="primary" class="">
-            <main id="main" class="site-main" role="main">
-                <article class="hentry">
-                    <div class="page-content">
-                        <h2>Projects</h2>
+<!-- 
+slug: /projects
+title: Projects
+-->
+${include page_top}
                         <p>Over time I&#8217;ve worked on a number of open source projects and websites. The list below is an incomplete list based on my recollection, but you can also check out my <a href="https://github.com/JonathanGiles/">GitHub</a> for a number of smaller projects I created.</p>
 
                         <br/>

diff --git a/src/main/resources/www/templates/fragments/header.html b/src/main/resources/www/templates/fragments/header.html
@@ -253,20 +253,6 @@
             border-color: #e8e6e6;
             border-style: solid;
         }
-
-        /* Improve image display, but on mobile, make images 100% width */
-        img {
-            display: block;
-            float: none;
-            margin-left: auto;
-            margin-right: auto;
-            width: 65%;
-        }
-        @media only screen and (max-width: 600px) {
-            img {
-                width: 100%;
-            }
-        }
     </style>
 
     <link rel='stylesheet' id='social-logos-css' href='/css/social-logos.min.css' type='text/css' media='all' />

diff --git a/src/main/resources/www/templates/fragments/page_bottom.html b/src/main/resources/www/templates/fragments/page_bottom.html
@@ -0,0 +1,5 @@
+                </article>
+            </main>
+        </div>
+    </div>
+${include footer}
diff --git a/src/main/resources/www/templates/fragments/page_top.html b/src/main/resources/www/templates/fragments/page_top.html
@@ -0,0 +1,15 @@
+${include header}
+<body class="page">
+    ${include hero}
+    <div id="content" class="site-content container-fluid">
+        <div id="primary">
+            <main id="main" class="site-main" role="main">
+                <article class="hentry">
+                    <header class="entry-header">
+                        <div class="entry-header-row">
+                            <div class="entry-header-column">
+                                <h1 class="entry-title">${title}</h1>
+                            </div>
+                        </div>
+                    </header>
+
diff --git a/src/main/resources/www/templates/jbp.html b/src/main/resources/www/templates/jbp.html
@@ -1,17 +1,4 @@
-${include header}
-<body class="page">
-    ${include hero}
-    <div id="content" class="site-content container-fluid px-2">
-        <div id="primary" class="">
-            <main id="main" class="site-main" role="main">
-                <article class="hentry">
-                    <header class="entry-header">
-                        <div class="entry-header-row">
-                            <div class="entry-header-column">
-                                <h1 class="entry-title">${title}</h1>
-                            </div>
-                        </div>
-                    </header>
+${include page_top}
                     <div class="entry-meta">
                         <a href="/jbp/index.html">Return to Java Best Practices home</a>
                     </div>

diff --git a/src/main/resources/www/templates/page.html b/src/main/resources/www/templates/page.html
@@ -1,22 +1,5 @@
-${include header}
-<body class="page">
-    ${include hero}
-    <div id="content" class="site-content container-fluid px-2">
-        <div id="primary" class="">
-            <main id="main" class="site-main" role="main">
-                <article class="hentry">
-                    <header class="entry-header">
-                        <div class="entry-header-row">
-                            <div class="entry-header-column">
-                                <h1 class="entry-title">${title}</h1>
-                            </div>
-                        </div>
-                    </header>
-                    <div class="entry-content">
-                        ${content}
-                    </div>
-                </article>
-            </main>
-        </div>
-    </div>
-${include footer}
+${include page_top}
+<div class="entry-content">
+${content}
+</div>
+${include page_bottom}
diff --git a/src/main/resources/www/templates/post.html b/src/main/resources/www/templates/post.html
@@ -1,17 +1,4 @@
-${include header}
-<body class="page">
-    ${include hero}
-    <div id="content" class="site-content container-fluid px-2">
-        <div id="primary" class="">
-            <main id="main" class="site-main" role="main">
-                <article class="hentry">
-                    <header class="entry-header">
-                        <div class="entry-header-row">
-                            <div class="entry-header-column">
-                                <h1 class="entry-title">${title}</h1>
-                            </div>
-                        </div>
-                    </header>
+${include page_top}
                     <div class="entry-meta">
                         <span class="posted-date">Posted on ${date}</span>
                     </div>
Original file line number	Diff line number	Diff line change
Expand Up		@@ -29,4 +29,4 @@ Fortunately, we do have tools on our side to keep us honest and aware of breakin

		The other kind of breaking change that we need to be very careful of is changes in behaviour. For example, if the `foo()` method is documented to always return `42`, and users begin to depend on this behaviour, it would be very unwise to change it to instead return `0` in a future release. The obvious solution to prevent this from happening is to introduce good quality unit tests to validate expected behaviour, and to ensure this does not change unexpectedly between releases.

		As mentioned in [JBP-6](/jbp/jbp-6), we should make sure to introduce code coverage tooling such as JaCoCo to validate that we are writing tests that cover these critical behavioural aspects of our code. Reading the reports generated by tools such as JaCoCo, we can very quickly identify code paths that may not be getting enough test coverage, and writing tests for these paths can help prevent accidental behavioural breaking changes.
		As mentioned in [JBP-6](/jbp/jbp-6.html), we should make sure to introduce code coverage tooling such as JaCoCo to validate that we are writing tests that cover these critical behavioural aspects of our code. Reading the reports generated by tools such as JaCoCo, we can very quickly identify code paths that may not be getting enough test coverage, and writing tests for these paths can help prevent accidental behavioural breaking changes.