All posts by visionarycoder

Reflections

I’m looking through old posts and doing a little site maintenance. I dumped another set of fake user accounts. I’ve updated the security settings, the PHP version, and the default template. I’m working on linking the certificate to the WordPress configuration. It’s not obvious to my tiny brain. I published a few things that had gotten lost in draft status. Some written years ago.

Continue reading Reflections

12 Factor Apps vs The Method

Red Hat dropped an article on 12 Factor Apps. Go take a look at that first. An illustrated guide to 12 Factor Apps | Enable Architect (redhat.com)

Now, download “The Method” from iDesign. Transform your software architect career (idesign.net) Filter: “Other” Look for “The IDesign Method.”

Perspective

Reading through the 12 Factor App article, I see huge overlap with what Juval has been advocating for decades. Lots of this material is directly stated or covered in the onsite training for “The Method.” 

Slicing apart components on the boundaries defined in The Method takes cares of a large percentage of the suggestions. 

Hiding data resources behind an accessor decouples persistence. 

All cross-cutting concerns should be treated as utilities, shared by all components in the development stack. Message brokers are infrastructure services either baked into the host platform or run as a utility.

The Method foreshadows everything in the 12 Factor App, with the possible exception of a single code repository. I don’t want to rabbit hole on this idea but why does your app have to use a single code repository? There are legitimate reasons to avoid this approach: legal; geography; network isolation/latency; etc.

Services

In the language design community, there is a push to make everything a service. Reference types and Value types can be services. The service could tell you the stored value, when it was updated/created, provide methods for manipulation, or any number of other things.  SAP’s Hana leverages a column-oriented database model which distills down to the idea that there is one and only one instance of any given data point. Sound familiar? There is no reason why we can’t follow this model in software applications. It’s already symbolically implemented in the Actor pattern.

Events

Next, consider all communication as events.  Calling a method is an event.  Writing to disk is an event.  Turning on an LED is an event.  Something “happens,” therefore it is an event.  

Baseline

Every value object is a service.

Every communication is an event.

How does this apply to 12 Factor and The Method?

The Argument

I’m going to pick only on Point 11 of the 12 Factors to show how the Method is embedded in the 12 factor approach. If anything, it give guidance on how to actually deliver on the 12 factor app schema.

Treat logs as streams of events. 

Why should this just be logs?  Why are logs special in the larger application design? Honestly, they are not special. It’s no different from any other event-driven activity.

All communications between objects are events. A “logging” event has a payload to describe the event. The event is posted to a channel where event subscribers can process the the event payload as needed. This is the exact same interaction model as a WCF channel managing RPC calls from a manager method to an interface implementation across component boundaries. This is all described in The Method.

Don’t get distracted by the details of the communication. The platform should make those details transparent to the developer. It doesn’t really matter if you use REST, Pub/Sub or Queues. All of these have cost/benefit ratios to figure out for your project. You need to pick the right technology that fits your needs. The Method provides a implementation pattern.

For me, the important part is seeing how Juval’s ideas predate 12 Factor Apps.

Returning to logs.

If everything thing is an event, why do we need a specialized logging model?  We don’t!

All events fire across one or more channels. Symbolically, a logging event is the same as an event requesting an action from another component. The subscribers to that log event channel can manage the required activity that fits the need. A logger can monitor a channel for published events to a tiny debugging log, handle application level logging on the device, committing the entry to a SQL data store or a non-SQL data lake for later analysis.

In conclusion

Do you see the possibilities with this approach?

Spend some time reviewing the 2 articles. Look at the 12 Factor diagrams, turn them sideways and see how Juval showed these same ideas over a decade ago.

Code Smells

At times it can be a challenge to figure out what’s wrong with an application or component. It’s just a nagging feeling in the back of your mind that something isn’t quite right.

For me, that’s a code smell.

Here are a few that I try to keep an eye out for and avoid at all costs in my development efforts.

  • Rigidity
  • Fragility
  • Immobility
  • Viscosity
  • Needless Complexity
  • Needless Repetition
  • Opacity

I strive for SOLID and DRY. Anything that violates those principles needs to be reviewed. Single-responsibility principle and Liskov substitution principle are biggies for me. Do one thing and do it really well. Wrap everything in an interface. Implementation details should always be hidden behind that interface.

The Purge

Recently, I moved around my Azure subscription. The site was down for a while and that was fine. I got everything spun back up, got everything updated and life was good. Eventually, I started poking around my site fixing broken links, removing unused templates, and the like. Along the way, I realized I have over 5,000 subscribers. None have ever posted a comment. Probably because I block all spam comments.

This got me thinking and purging… I removed all @*.ru subs. I started to see naming patterns, patterns that were obvious to human eyes but not machine eyes.

So…

I’m dropping all subscribers that don’t have an avatar. If you think I dropped you and you still want to subscribe, please re-up. I am also adding 2-factor authentication which should help limits bots from setting up more of these bogus accounts.

Retrograde

VERB:

  • archaicgo “back in position or time.”

I joined a new team a few weeks ago. I’m now a Technical Program Manager. I’m working with a validation team in systems integration.

I’m out of Corporate IT, which is good in my opinion. I prefer to be in the business, delivering direct business value without regard for my actual role.

Retrograde.

The flip side is learning a whole new domain. It’s a lot of effort and I have no idea which way the wind is blowing. I am learning lots of new things.

Retrograde.

Cool.

Anti-Patterns with CONSTANTS.

I have a habit that’s probably an anti-pattern. I like to nest classes in a constants file.

  1. I always call the file Constant.cs. Singular. It goes at the root level of my Framework project. This should be accessable from every other project within your solution.
  2. The class is a static. Therefore, all of the subclasses are static as well.

Normal Constant file

public static class Constant
{
  public const string Title = "My Title";
  public const string EmailAddress = "foo@bar.com";
 }

Now consider this…

Nested classes

public static class Constant
    {
 
        public const string Title = "My Title";
        public const string EmailAddress = "foo@bar.com";
 
        public static class Color
        {
            
            public static class White
            {
                public const string Name = "White";
                public const string HexCode = "#FFFFFF";
            }
 
            public static class Black
            {
                public const string Name = "Black";
                public const string HexCode = "#000000";
            }
 
        }
 
    }

Usage

public class Usage
    {
        public void Example()
        {
            var blackHexCode = Constant.Color.Black.HexCode;
        }
    }

I like how this creates a clean hierarchy to reference a constant. As I said, this is probably an anti-pattern. But it works for me.

Slippage

Ouch!

I hadn’t realized it had been so long since I posted. That said, I’ve been rather busy. Family stuff, work stuff, relocation/new house stuff, health issues, new motorcycle stuff, etc. Basically, life stuff.

I changed teams which required me to move back to Oregon full-time. Hence the relo/house issues. At this moment, I’m working on a mobile app team, doing Xamarin development for an internal app on Android and iOS target platforms. And I’m still keeping my toes in the Application Architecture team. They are going through some churn right now as Senior management realigns.

We have a new IT leader. I don’t remember if she is the CTO or CIO. It doesn’t really make any different from where I’m sitting. I like what she had to say in her first public forum. I heard pragmatism over dogma. I didn’t hear the whispers of highly paid consultants forcing unneeded changes if only to justify their presence. But… We’ll see how it goes.

So.

There has been a little slippage. I might even do something about it, but I need to heal up from my last surgery. Having already torn a couple internal stitches, I might actually take it easy for a week or two.