Free AI web copilot to create summaries, insights and extended knowledge, download it at here

4709

Abstract

de> command with parallelism.</p><h2 id="9570">Benchmarks</h2><p id="dc98">Benchmarks conducted on four different repositories revealed that a hot mvnd execution, where the daemon is already running, can accelerate builds by up to 50% of builds that do not run tests or static analysis as this is the most common use-case among developers in our organization.</p><figure id="442c"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*xot8KoV94usih-4e"><figcaption></figcaption></figure><h2 id="77be">Local vs CI server</h2><p id="ac6e">Using Maven Daemon significantly sped up our local builds, making our engineers’ daily iterations faster and more efficient. However, this solution wasn’t suitable for our CI environment with TeamCity. Since we don’t reuse TeamCity, there was no benefit to starting a daemon process in this context.</p><p id="3916">In response to this limitation, we will be exploring the possibility of reusing agents and investigating potential improvements in a different initiative to better optimize our CI environment.</p><h2 id="c57d">Adoption</h2><p id="8fb7">To ensure every Java team at Picnic could benefit from the increased speed of local builds using Maven Daemon, we created a comprehensive knowledge article outlining the steps and best practices. By sharing this detailed knowledge article, we ensured that all developers in our organization could easily adopt and benefit from using Maven Daemon, leading to faster build times and improved productivity.</p><p id="436d">Currently, we don’t have visibility in the adoption rate here, but we are looking into using OpenTelemetry Maven extensions to get more insights into this to better track and advocate</p><h1 id="aceb">Maven Build Cache</h1><p id="6a2a">One of the best ways to speed up builds is to do less. And the best way to do less is to eliminate duplicate or unnecessary work. Why should we want to rebuild and retest all modules in our project if I change a single test, or a small if-statement in a module no other module depends on? We can use a build cache to only execute Maven goals for modules that changed and modules that depend on these changes.</p><h2 id="f90a">How does it work</h2><p id="5cdc">The Maven Build Cache extension enhances the efficiency of large Maven projects by implementing the following set of features:</p><ol><li><b>Incremental Builds</b>: Only the modified parts of the project graph are rebuilt.</li><li><b>Subtree Support</b>: Allows isolated builds of specific parts in multi-module projects.</li><li><b>Version Normalization</b>: Facilitates version-agnostic caching.</li><li><b>Project State Restoration</b>: Avoids repeating expensive tasks like code generation by restoring previous states from the cache.</li></ol><figure id="5b07"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*ehx_WSQV_zw9e68p"><figcaption>The diagram shows that changes in a module (Module 2) lead to it and its dependents (Module 3) being rebuilt, while unchanged modules (Module 1 and Module 4) are retrieved from the cache.</figcaption></figure><h2 id="28f6">Local Build Cache</h2><p id="2678">When working locally, the Maven Build Cache stores the build output artifacts in a designated local cache directory. Here’s a step-by-step breakdown of how it operates:</p><ol><li><b>Initial Build:

</b>During the first build, Maven compiles the entire project as usual.
For each module, the build cache extension computes a unique hash based on the module’s inputs (source files, Maven configuration, dependencies, etc.).
The build outputs (e.g., compiled classes, packaged artifacts) are stored in the local cache directory with the computed key.</li><li><b>Subsequent Builds:
</b>Before building a module, Maven checks the local cache directory to see if there is a cached result for the module’s hash.
If a match is found, the cached outputs are restored, and Maven goals executed when the cache was constructed are now skipped.
If no match is found, Maven rebuilds the module, and the new outputs are cached for future use.</li><li><b>Cache Management:
</b>The local cache can be configured to limit its size and manage the retention of cached artifacts.
Policies can be defined to periodically clean up old or infrequently used cache entries, ensuring the cache directory remains manageable.</li><li><b>Key Generation:
</b>The unique key for each module is generated by hashing the module’s inputs. This includes source code files, project model (POM file), plugin configurations and parameters, and dependency versions and configurations.
By including all relevant inputs in the key, the build cache ensures that any change in the inputs results i

Options

n a new key, prompting a rebuild.</li></ol><p id="4903">The build cache uses hashing to generate unique keys for storing and restoring build results. Correctness is maximized by including all relevant files and functional plugin parameters, while reuse is enhanced by filtering non-essential files and minimizing controlled plugin parameters. Configuration involves balancing correctness and performance through an XML file, <code>buildinfo.xml</code>.</p><h2 id="88d2">Usage in CI</h2><p id="6966">In our CI process, we also leverage the Maven Build Cache solution to accelerate our CI builds. However, for CI, we employ <a href="https://maven.apache.org/extensions/maven-build-cache-extension/remote-cache.html">a remote cache</a> stored in an artifactory instead of using a local directory. In our case, cached artifacts are stored in Nexus. This approach has markedly increased the speed of our Java builds. Consequently, our builds finish sooner and build queues are shorter.</p><p id="d0a3">However, in certain situations, users need to perform a full build of their changes. To accommodate this, we introduced a TeamCity parameter called “Use Maven build cache” with the following options:</p><ul><li><code>true</code>: the cache is used</li><li><code>false</code>: the cache is not used</li><li><code>default</code>: the repository-level setting is applied</li></ul><figure id="51f5"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*cjBQGpXtPyo_8MeafHw1TA.png"><figcaption></figcaption></figure><p id="76d0">It is good to note that we currently employ the cache only for builds that do not create production artifacts, as we wish to have these as ‘pure’ as possible. As such, we disable the cache for builds on default branches supporting continuous deployments, and in release builds.</p><h2 id="1253">Benchmarks</h2><p id="12d5">In the best-case scenario, the execution time of CI builds dropped by ~ 90% when execution of every module was skipped, this is how it was shown in the build logs:</p><div id="bdae"><pre>[INFO] Skipping plugin execution (cached): <span class="hljs-keyword">install</span>:<span class="hljs-keyword">install</span></pre></div><p id="72cd">Instead of 10 minutes 4 seconds, the build that was fully cached took only 1 minute 22 seconds. 😲</p><p id="fb1e">Of course, this is quite a rare case to run a build that has every module skipped. The average build time improvement across all Java repositories in Picnic is shown in the picture below. It is noticeable that build time dropped by 62% in general.</p><figure id="3fd7"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*m9KcQpIhbc66wTHDIvttPQ.jpeg"><figcaption></figcaption></figure><p id="97f1">For some repositories, the build time improvement was more noticeable than for others. Projects with many modules benefit more than projects with only a few modules. This can be seen in the chart below showing P75 build times. Highly modular projects see their build times drop from 10 to 5 minutes. Projects with a few modules only benefit little from this improvement.</p><figure id="8e53"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*Qp8AmIXK7M0xzbuc"><figcaption></figcaption></figure><h1 id="d1eb">Conclusion</h1><ol><li><b>Dramatic Build Time Reduction:

</b>Build times dropped from 12 minutes to 8 minutes in general. This significant improvement eliminates long waits, allowing developers to maintain focus and productivity.</li><li><b>Enhanced Developer Experience:
</b>Faster build times, especially for local builds, lead to fewer interruptions, enabling developers to stay in the zone and work more efficiently. This improvement has contributed to higher job satisfaction and overall happiness among our teams.</li><li><b>Increased Efficiency in CI Pipelines:
</b>Using the Maven Build Cache in our CI environment has sped up CI builds, reduced queue times, and made TeamCity agents available more quickly.</li></ol><p id="46a2">These improvements have significantly boosted developer morale and productivity. Reduced build times mean less context switching, quicker feedback, and a more enjoyable workflow.</p><p id="316d">Developers feel more empowered and efficient, resulting in higher-quality code and faster feature implementation.</p><p id="90d2">In summary, the integration of the Maven Build Cache extension and Maven Daemon has transformed our build process, making it faster and more efficient. We are excited to continue leveraging these tools to maintain and further improve our build processes, ensuring our developers have the best possible experience.</p><p id="0bd6">In collaboration with <b>Pieter Dirk Soels</b></p></article></body>

4 Reasons My 1Password Article Went Viral

The numbers are BONKERS

To date, my 1Password 8 article has attracted more than 104,000 views on Medium.

It has also somehow amassed over 932 hours of member reading time and earned more on the Medium partner program by itself than I usually earn for 20 or so individual articles each month.

The 1Password Disaster (And Two Brilliant 1Password Alternatives)

What’s happened to the world’s most-loved password manager?

medium.com

This blog post consists of around 950 words and took me about 40 minutes to write. I wrote it, forgot about it, and moved on with my life.

Then, it exploded.

More importantly, it resulted in an interview with two figureheads at AgileBits (the team behind 1Password), personal interactions with founder Dave Teare, and an avalanche of comments from their incredibly passionate fanbase.

Here’s why I think it worked.

1. I was stuck for something to write that day

I publish five blogs every week and, trust me, inspiration isn’t always easy to come by. Even with a bulging list of ideas in the bank, I often wake up and realise I don’t want to write any of them.

That’s what happened on the morning of August 13th. I took one look at my list of planned articles and not one jumped out. So, I made a cup of coffee, flicked open my MacBook Air, and caught up on the latest discussion on my Discord server instead.

Everyone was talking about 1Password 8.

So, I wrote about it.

2. I sat on the fence

When I wrote my 1Password 8 article, I wasn’t a 1Password user (I’m in the process of switching to it now for a thorough test). I also had no strong feelings about Electron, the platform on which 1Password 8 is based, and the root cause of most of the backlash.

So, I sat on the fence. I gave some brief insight into the story so far, provided the simplest explanation of Electron I could muster, and sympathised with both parties.

If you’re an aspiring blogger, journalist, or columnist, there is nothing wrong with sitting on the fence. If you have no strong leaning in either direction but want to write about a highly divisive topic — do it.

An Interview With 1Password: What’s Going on With 1Password 8?

It’s time to hear the other side of the story

medium.com

3. I offered to help

I like helping people who have tech-based conundrums. It’s the reason I created this entire brand.

My 1Password article was no different. After my bout of fence-sitting, I decided to offer a couple of alternatives for anyone who had made the decision to leave 1Password.

The first was Apple’s very own Keychain, which is just about the best, most secure, and ridiculously convenient alternative for anyone who sits deep within the Apple ecosystem.

The Best Password Manager Is Right Under Your Nose

Why would you use anything else?

medium.com

The second was a bit of a disaster in itself. I suggested that people should try NordPass as an alternative, which, as it turns out, also runs on Electron. And, yes, it’s subscription only, too (another significant grumble about 1Password’s new direction).

Alas, NordPass has been a long-term sponsor and supporter of my channel and that means a lot. I also like their software. So… whatever.

4. I thought (a little bit) about SEO

In a little over a year, I’ve somehow built a tech review brand with a combined monthly audience of around 78,000 people. I’ve done this without spending much time on search engine optimisation (SEO). At all.

I know this is silly, and I know it needs to change, but if my 1Password article’s success proves anything, it’s that bare-bones SEO is often all you need.

However, I admit that I adopted more of a common-sense approach for this particular article (which, I’d argue, is exactly what SEO is all about). I knew people would be searching for 1Password alternatives, and I had a feeling the word ‘disaster’ would be regularly attached to the situation.

That’s why the article was titled ‘The 1Password Disaster (And Two Brilliant 1Password Alternatives)’. For good measure, I lobbed the keywords’ 1Password 8' and ‘1Password alternatives’ into the meta description and alt image tags, too.

Then, I simply wrote the rest of the article, and, clearly, got the keyword density bang-on — without even thinking about it.

My stats prove that my hunch was correct. The most searched query for people visiting my website’s version of the article was indeed ‘1Password disaster’.

To be continued…

The AgileBits team has been incredibly supportive over the last few weeks; I cannot speak highly enough of them when it comes to the grace and respect with which they’ve approached this coverage. There was no question screening before the interview, and even though I sent the finished version to them as a matter of courtesy, they didn’t request to see it before publishing.

Remember — this is a company to whose product I attached the word ‘disaster’ in my article title. Call it click bait if you like — I genuinely don’t care; I just wanted eyes on that piece, and they clearly respected my creative decision. How refreshing.

Attention is currency in the digital age, and the amount I’ve earned with my 1Password article really has taken me by surprise. But I’m not finished yet.

Stay tuned.

Before you go

Join my behind-the-scenes mailing list

If you enjoy my writing, it’s only a snippet of what’s on Medium. I’m a paying member myself and highly recommend joining. Click here to do so (a portion of your membership fee will be sent my way and therefore directly support my work!). Join here.

Originally published at https://markellisreviews.com on September 9, 2021.