Help your co-developers grow - by meeting them where they are!

That is the theme of this little video I made, by request from Majid Mostafavi from the Iranian JUG (topic was developer soft skills).

Happy International Developers Day 😊

https://www.youtube.com/watch?v=EpEbT5bYNb4

I have updated my Java tutorial introduction to list what is new in Java 23. The list of new features now lists all the major features in each release, back to Java 7.

https://jenkov.com/tutorials/java/index.html

I have updated my Java ConcurrentMap + ConcurrentHashMap tutorial - and made a video version of that tutorial. Here are the links:

https://jenkov.com/tutorials/java-util-concurrent/concurrentmap.html

https://www.youtube.com/watch?v=OGXAs9fZYTc&list=PLL8woMHwr36EDxjUoCzboZjedsnhLP1j4&index=28

Note: the video link has been fixed now! 😊

I have improved my Polymorph Data Encoding specification significantly, so it is now easier to understand. The specification is hosted in a GitHub repo (see link below).

I will now proceed to provide a proof-of-concept implementation of a reader and writer utility in Java - for anyone to use - or just to see how to implement reader and writer functionality in other languages.

If you are on the lookout for a data encoding that gives you (almost) everything you get with JSON, XML, YAML, CSV, MessagePack, CBOR, Protobuf, ION etc. - and yet also gives you compact tabular data, compact trees and cyclic object graphs (plus other nice features), with high performance and a compact encoding, Polymorph Data Encoding might be an option for you!

https://github.com/jjenkov/pde-pdl-specification/blob/main/pde-specification.md

I have released the first drafts of writer and reader code in Java for writing and reading raw, binary Polymorph Data Encoding (PDE). It's located in this GitHub repository :-)

https://github.com/jjenkov/polymorph-fabric-java

Now PDE is no longer just an idea - no longer just speculative 😊

Now you can see how to actually work with it 😊

More details will come in the future, of course 😊

When being serious about Compositional Software Design (designing your code base for composability) - you will often experience these two phenomena impact your code base size:

1) Decompositional Expansion

2) Compositional Contraction

First, your code base will expand because you are breaking your code base into many smaller pieces that can be composed together to form solutions. This phenomenon (phase) is what I call the "Decompositional Expansion".

Later, your code base will feel like it contracts, meaning it does not grow as fast in size anymore as it did in the beginning. It feels like you can add new functionality with little code (and little effort). This phenomenon (phase) is what I call the "Compositional Contraction". During this phase you are starting to reap the benefits of all those reusable components you created during the Decompositional Expansion.

Have you experienced these two phenomena in your code base size growth? ☺️

I am covering these phenomena in my upcoming video about Compositional Software Design ☺️ Seems like it will be one of my longest videos to date! 🫢

Imagine a desktop platform that:

* Comes with multiple smaller apps embedded.

* Lets you script which apps to open in which Windows, on which screens,
and which data to load in those apps.

* Lets you create your own apps and plug in.

* Can connect all the world's users of this platform into a single global P2P Network, made up of lots of smaller, local P2P Networks connected together in a P2P polyring topology.

* Lets you exchange scripts and data with other users via messaging -
and enable your apps to communicate with other users' apps.

Imagine then all the knowledge and technology that can come out of such a project. And just as importantly - all the fun !! 😉 😊

That is what the Polymorph Personal Compute Platform is aiming at ☺️

Your software design choices matter.

In 2006 I released a version of my dependency injection container called Butterfly DI Container - which was feature-wise about on par with the Spring Container and Google Guice. However, the size of the code bases were quite different:

- Spring Container: 1,000 KB JAR file
- Google Guice: 500 KB JAR file
- Butterfly DI Container: 100 KB JAR file

That is a factor 5 and 10 more code in Guice and Spring than in Butterfly DI - to provide essentially the same functionality.

I did not analyze why that difference was so big.

I just noted internally, that there are many ways to solve the same problem - to implement the same functionality - and the difference in code base size can be quite big.

Is that perhaps one of the secrets of the " N x developers " - that they are able to solve the same problems with less code than others?

Here is my video about Compositional Software Design !

This video explains what I mean by compositional design, and explains the SCIFI principles that can guide you when designing for composition. It also explains concepts such designing for replaceability and two-way reusability. It also discusses when to use an interface, and when not.

I have been working on the content of this video for more than 1.5 years - and promised this video several times - before I finally got the core ideas distilled enough to convey in a video 😊

The ideas are reasonably simple - but it has taken a long time for me to make them this simple 😁

https://www.youtube.com/watch?v=rmEh3E1ZIfU&list=PLL8woMHwr36HWMaOTIiWNf_fYYkZCHPxo&index=9

I have updated my book about P2P Networks with more details about the P2P topology I have invented - called the Polymorph Polyring P2P topology.

More specifically, I have added details about:

- Alternative GUID schemes (strings instead of numbers)
- Ring leaders
- Broadcast
- Multicast

The Polymorph Polyring P2P topology has better support for shaping the topology - e.g. according to the geographical location of the peers.

The Polyring also has better support for broadcast and multicast than uniring topologies such as Chord, Kademlia, Pastry and Tapestry. This is one of the aspects I have added details about in this latest version of the book.

You can find the book on LeanPub, here:

https://leanpub.com/p2p-networks

I have published a short video about Method Chaining - that simple technique which enables us to express creation, configuration and assignment of objects more concisely.

I know most of you already know method chaining - but I needed this video as a prelude to my next video about Access Scoping - which is a technique that provides about the same benefits as method chaining- but which does not require you to design your code to support it.

Here is my video about method chaining 😊

https://youtu.be/ce65auIRpYo?feature=shared

I have published a video about what I call Access Scoping - a very simple design technique which brings benefits similar to method chaining (my previous video).

https://youtu.be/MHkmgQT7Rxo

Access scoping is a bit more verbose than method chaining - but you don't have to explicitly design your classes to support access scoping - like you do with method chaining.

Also, access scoping gives you full up-reach and self-reach during object graph creation - unlike method chaining which only gives you limited up-reach and self-reach (only on the call chain - not off).

Access scoping is similar to, but not the same as, the "with" operation in some languages.

Access scoping is also similar to Kotlin's scope functions - but Java does not yet have those, as far as I know (but I could be wrong) .

I would like access scoping to eventually be a language feature with syntax support... just like the for-each style loops in Java 😊