Posts

Showing posts with the label pattern

Microcontroller - service connections and acquisition patterns

Image
I ended up with some crosscutting content when I wrote up some patterns for getting data onto and off of microcontrollers. The consumption and generation patterns are cross-matched with implementation details.  You may know where you want to send data or in how many directions you want to send data. Now you have other concerns.  Connecting the devices, triggering transfers, and balancing latency with overhead. The next step is to understand how you are going to handle the connectivity and connection initiation.  That depends on the connection types, network topologies, and tools you have.  You then need to figure out how you are going to know when to capture data or receive commands.  Is it time-based or event-based?   Then you need to understand what your payloads look like and balance that against CPU, latency, and other constraints. This was just a subset but should give you the idea. Related Video Moving IOT data onto the controller Moving IOT data...

Patterns for Moving data onto a Microcontroller

Image
Microcontrollers can operate independently in complete isolation. They can operate independently while sharing data with dashboards or other applications.  They can operate under guidance or based on information provided to them by external systems.  They can coordinate operations with other controllers, or remote applications by passing data back and forth.  Let's break this down and talk about moving information onto an IOT from remote systems or other devices. We're talking about information transfers   from  a microcontroller to  other devices, applications, and data sinks.  Transfers can be   self-initiated  or   externally initiated .  Both approaches have their advantages and disadvantages. Video Moving IOT data onto the controller Moving IOT data off the controller Microcontroller - service connections and transfer patterns Related Blog Articles Patterns for Moving data onto a Microcontroller Patterns for Moving data off of...

Patterns for moving data off of a Microcontroller to somewhere else

Image
Microcontrollers can operate independently in complete isolation. They can operate independently while sharing data with dashboards or other applications.  They can operate under guidance or based on information provided to them by external systems.  They can coordinate operations with other controllers, or remote applications by passing data back and forth.  Let's break this down and talk about moving information from an IOT to remote systems or other devices. We're talking about information transfers from a microcontroller  to other devices, applications, and data sinks.  Transfers can be self-initiated  or externally initiated .  Both approaches have their advantages and disadvantages. Video Moving IOT data onto the controller Moving IOT data off the controller Microcontroller - service connections and transfer patterns Related Blog Articles Patterns for Moving data onto a Microcontroller Patterns for Moving data off of a Microcontroller Microcontr...

Append Only Data Patterns - Cloud Key Value Stores

Image
Cloud Key/Value databases have some interesting features and limitations that can change the way we model our databases. There is a class of key/value stores that have native change feed support that is in a form that is easy to connect to and operate against. In CQRS, we capture an event stream in a primary store and then materialize that in a query store.  An alternative to the CQRS pattern is to create an updated version of a document and then append that updated version of the document to the database.  We're going to look at the drivers and patterns for the latter approach. Video Presentation Content  Speaker's Notes to be added later Published 2022/10

A Software Architecture's Greatest Strength is Its' Greatest Weakness

Image
An approach's greatest strength is also often its greatest weakness.  You see this in Software Designs or Software Architecture.  We design something to be optimized around a set of needs, business functionality, ease of development, ease of maintenance, data integrity, performance.  Those decisions create their own problem.  We design and build systems optimizing our design around delivery capability, technology, NFRs, and business functions. Those designs and systems architectures take into account the best practices at that time . Those best practices sometimes come from other companies with different priorities and skillsets. The great strengths of your present-day designs will make up a good percentage of the future weaknesses. This should not be a surprise. We design around what we know now and around the technology available at that time.   Your successors will toss your design in the future when the strengths of the current approach become the thi...