Berlin Brown is a professional software engineer with more than a fifteen years of professional application development experience that has a proven track record of producing quality distributed software. My non-professional programming career started in Austin, Texas when I was 10 years old with the TRS-80 with early BASIC (Tandy RadioShack) and I haven't stopped programming since. My current focus technology stack includes Java enterprise web, mobile application development for Android and iOS. I am currently working with a financial services company (formerly a Citigroup unit), also with the City of Atlanta on a billion dollar engineering project and the Center for Disease Control (CDC) for a public health data collection module.
Specialties: AI, LLMS, AGI, Monty, Alife, Backend Java development, Frontend Hybrid development IBM Mobilefirst/Worklight, J2EE, performance analysis, web application security, IBM Webshere, IBM DB2 with a focus on Financial Services and Insurance. With new focus on #Atlanta, #AI, #LLM, #Blockchain
JVM Notebook - Small projects demonstrating the features of various JVM languages including scala, jython, drools, antrl, abcl. A collection of concise projects showcasing the capabilities and features of diverse JVM languages, including Scala, Jython, Drools, ANTLR, and ABCL.
Java Clojure PDF Generator - Simple editor written in Java Clojure. A lightweight, versatile text editor implemented using Java and Clojure, demonstrating seamless integration of JVM languages for practical tooling.
Updated OpenGL, Libgdx, Cellular Automata Examples OpenGL, Libgdx examples
Squirm Artificial Chemistry Java 2D game demo, redo A 2D simulation game in Java demonstrating principles of artificial chemistry, redesigned and updated for improved interactivity and visualization.
Simplest Possible POC Projects -
Small Reddit Like Site in Java - Post links to webapp, comments and more A compact, Reddit-inspired web application built in Java, featuring core functionality for posting, commenting, and content organization.
https://x.com/BerlinBrownMech - twitter, berlinbrown - new
Bluesky - Bluesky Link
A New Kind of Science
The name Stephan Wolfram has been mentioned several times in this post. He is the founder of Wolfram|Research, his company is known for the popular Mathematica software suite and Wolfram|Alpha knowledge engine. He did not initially discover cellular automata but recently he has been a prominent figure in its advocacy. He spent 10 years working on his book, A New Kind of Science. In the 1300 page tome, he discusses how cellular automata can be applied to every field of science from biology to physics. NKA is a detailed study of cellular automata programs.
Basic Cellular Automata
Figure: Wolfram's Elementary CA Rule 30. Look at 3 bit input and 1 bit output. An elementary cellular automaton takes a 3-bit input and produces a 1-bit output. The diagram above depicts Rule 30, one of Wolfram’s most famous elementary cellular automata. There are 8 possible input states (2³), each mapped to an output of 0 or 1. For example, an input of {1 1 1} produces an output of 0. The next input {1 1 0} also outputs 0. By repeating this process across a grid of cells, complex patterns emerge, even though the underlying rules are extremely simple. This illustrates the power of cellular automata: simple deterministic rules can generate surprisingly intricate and unpredictable patterns.
Applied Cellular Automata - Cellular automata have found applications in fields as diverse as data compression, cryptography, artificial intelligence, urban planning, financial market modeling, music generation, and 3D terrain generation. For software engineers and scientists, understanding the dynamics of cellular automata often requires stepping back from standard programming libraries and observing how patterns emerge from simple rules. Summary The simple squaring example mentioned in this post merely gives you an overview of a basic cellular automata system. Scientists, biologists, computer scientists and software engineers want to find better ways to observe relationships and patterns that occur in our world. Review Stephen Wolfram's A New Kind of Science to give you an idea for what is possible with seemingly simple rules.
I'm particularly interested in the psychology of unit testing — who does it, who likes it, and who hates it? Unit testing is one of those concepts that is easy to learn but hard to master. Consider chess as an analogy. Many people play chess casually when they're young, yet most never become strong players. I am part of that majority. I’ve never sat down for hours trying to master chess. I don't see the common patterns, I haven’t developed an endgame strategy, and my knowledge is limited to the basic rules. Unit testing in software development is similar. It's straightforward to understand at a surface level — write tests, run tests, check results — but mastering it requires discipline, practice, and experience. Of course, there are big differences. Chess is a game, whereas software development is serious work. And unlike chess, unit testing often exists in a professional context where the stakes involve real business risk. If a developer doesn't fully master unit testing but still completes their tasks effectively, some might argue that this is an acceptable risk in many development environments. So why strive to master unit testing at all? Some developers may simply not want to invest the energy required to reach mastery. In other cases, a company's culture or policies may not enforce rigorous testing, making it optional rather than mandatory. Nevertheless, those who do commit to mastering unit testing often find that their code is more reliable, maintainable, and resilient in the long run — much like a chess player who gradually learns to anticipate patterns and plan ahead.
I am not going to convince you to write unit tests with this one post, I will leave that up to software guru Martin Fowler and the people at ThoughtWorks who have written large tomes on the subject. But I will present my thoughts on why some developers won't write unit tests but why they should. Those developers and architects that do advocate unit testing generally fall into that category where they have written just enough unit tests to find it useful and they generally love the practice, they also encourage others to follow along. I am sort of in that camp, I have almost become religious about it. I can't imagine my real code without unit tests and I just feel guilty by only testing through manual functional testing.
Jeff Atwood of Coding Horror wrote a short blog post on the topic, "I Pity the Fool Who Doesn't Write Unit Tests". Here is the one blurb that stuck out for me, "Even if you only agree with a quarter of the items on that list-- and I'd say at least half of them are true in my experience-- that is a huge step forward for software developers". And this one, "It's more fun to code with them than without". That is the essence of this unit testing religion, we can't force it on developers and we can't force developers to write unit tests only a certain way. I and many others don't believe in the practice of 100% coverage. You will rarely get there anyway, depending on the project or company. Some will argue that you shouldn't break the rule on non-determinism and this is a big one. Basically, the unit test should return the same output every time you run the test. You should avoid breaking this rule for unit tests but you can still write and add automated integration tests to your suite and not waste time, combine a collection of unit tests and integration tests. A simple integration test might test connecting to your REST microservice and validating the HTTP status code. At that point, your test moves into the integration testing category. If you connect to the database, run a particular SQL statement and validate data model returned from the SQL invocation, then your test is basically integration. Both scenarios are not units are non-deterministic but I would still consider them to be useful. Also, as a start for new developers getting familiar with unit testing, writing integration tests may be more familiar to them than decomposing or refactoring their code for a real unit test. There is a benefit in database or HTTP integration tests, you can add them to a test suite and run them in a automated form after a code change and after a build. Even bad tests can be useful.
Misko Hevery is creator of one of the most popular JavaScript frameworks to emerge in the last couple of years. It is a Google project that he started working as an Agile Coach. As he puts it, he wants to maintain the high level of automated testing culture at Google. Most of his published articles are not about AngularJs but on the benefits of automated testing. I can only imagine that he developed the MVC JavaScript framework because the old crop of frameworks were a pain to work with for developers. They were not testable.
The Java Virtual Machine ( Sun's JVM is called HotSpot ) is a java bytecode interpreter which is fast, portable and secure. Jython, JRuby, Scala, ABCL (Common Lisp) are popular language implementations that run on the JVM that allow for the jvmcookbook sugar of their particular languages.