Skip to content

Study Journal 13-11-2023

Published: at 12:00 AM

Where I’m at

Onward - Finishing up the Stocktake Form - Initialisation, Completion and Submission

Status update:

  1. Initialisation - nearly complete
  2. Completion - about halfway
  3. Submission - not much progress — have psuedocode for submission logic

Tasks for completion for today:

What I learnt

Random thoughts to checkout

From “Pragmatic Thinking and Learning”

Finished Chapter 3 - This Is Your Brain:

CPU 1 vs CPU 2

Basically there’s two modes of thinking - people consider this left / right brain. It’s a bit more nuanced than that and can be more accurately described as linear mode and rich mode:

ItemL-ModeR-Mode
DescriptionLogicalEmotional
StrengthsWorking through details, logical thinking
Analysis - learning by pulling apart
Intuition, problem solving, creativity
Synthesis - learning by building
MemoryShort-term memoryRetrieval for long-term memory and ideas that are “in process”
ConsciousControllable - often described as the conscious brainUncontrollable - sort of like peripheral vision
StorageStores only a fraction - good at indexingStores everything - poor at indexing
RetrievalSearching narrowlySearches all memory - including unindexed memories
VerbalVerbalNon-verbal - can retrieve words though
Order of RelatingAbstractions of objects (Small piece of object extracted to fit the larger picture)Concrete relationships between objects
TimeAware of timeUnaware of time
DeterminesAnswersQuestions
Level of ThinkingLow levelHigh level

Capture your thoughts 24/7

The brain (both sides) is constantly offering up good suggestions!

Take note of them – The brain produces more of what you think is worth paying attention to!

For me I know that writing on the whiteboard is the best way to do so

Acting vs Ideating

Keeping track of your ideas is the first step in acting on your thoughts.

Using R-mode in learning

Selection - creating attractive things

Rewiring your brain for learning

Portal - Development

Data and State Management Model

  1. Data Models
    1. Think of this as what am I actually trying to capture for later use? E.g. stock item name, count, location, etc
      1. Consider not only what data you are trying to capture - but also maybe how you will create relationships between other models - stock item model that defines a itemId that is then also used in the stocktake model. Also consider metadata requirements - e.g. the dateTimeof the stocktake or the users id.
      2. Think in terms of the object, and also relationships. Metadata is really just a special relationship with the functioning of the application.
      3. To figure these out - you must understand what exactly the purpose of the feature is doing. What is the stocktake feature in exact and precise terms doing?
        1. Streamlining the stocktake count process by giving a more user friendly interface (e.g. only showing user relevant data)
        2. Helping the user with more context specific information to help guide the users (e.g. showing the last count numbers on a new stocktake being initialised)
        3. Getting more quality data inputs to guide business decisions (e.g. ensuring quality through only presenting appropriate UI elements and or validation logic)
  2. States
    1. Think of this is as a snapshot of data that I’m trying to capture. While not all data is displayed, what is - do I need to hold onto it?
    2. Flutter will recreate each widget when there is a change this means - do I need to instruct Flutter to not recreate this part of the widget when that change occurs?
    3. So imagine it as we’re taking a snapshot - and then tell me what information we need to capture. This data will then be held either to be held in the database, affect other state changes, etc.
  3. Notifiers
    1. Think of this as what is taking the snapshot and or changing things - it is executing the logic of the application (the change element between data and UI)
    2. This is best thought as “If I have this data - the visuals needs to change this way” or “The user used the UI - the data needs to change this way”
    3. The Notifier can do this either by it’s own methods (the real logic of the application) and by also incorporating methods from repositories.
    4. StateNotifiers - A combination of both, best to leave complex state management to separate States / Notifiers in my opinion. StateNotifiers are useful for basic or singular implementations such as intialisation or submission logic.
  4. Repositories
    1. This is a collection of methods to accessing data into the application. In concrete terms this is a CRUD call to Firestore.
    2. This can also have more specialised methods for particular methods - such as intialisation or submission methods
    3. Can depend on interfaces that allow for easy refactoring of how methods are implemented - e.g. instead of calling Firestore, we can check local device data.
  5. Providers / Consumers
    1. Providers are simple methods that give access to all the methods defined in the Notifiers, and Repositories
      1. If we are saying here’s the data (the model), and this is relevant to the UI (the state), because when X happens then Y changes (the notifiers or repositories), then we need a way to access all of those classes. This is where the Provider comes in.
    2. The Consumer is simply the opposite - where a widget can read the Provider and implement the logic as intended.

Development Pathway

  1. Data - Models
  2. UI - Placeholder widgets
  3. State Management - Integrate logic
  4. Integration
  5. Testing
  6. Deployment
Consider supporting this blog