Skip to content

Instantly share code, notes, and snippets.

View nadeem4's full-sized avatar
🏠
Working from home

CodeWithNK nadeem4

🏠
Working from home
View GitHub Profile
@nadeem4
nadeem4 / Agent_Decision_Flowchart.csv
Last active June 22, 2025 16:30
This flowchart helps visualize the decision path from a basic agent to an AI agent based on task complexity and environmental dynamics. It could show questions like "Is the environment static?" or "Does it need to learn?" leading to the appropriate agent type.
Feature Normal Agent AI Agent
Learning No learning or adaptation Learns and improves over time
Decision Follows explicit "if-then" rules Reasons, adapts, makes smart choices
Environment Static, predictable Dynamic, unpredictable
Complexity Simple, repetitive tasks Complex, adaptive challenges
Cost Generally lower development costs Higher initial development costs
To Override This host.json Setting Create This Environment Variable
"functionTimeout": "00:10:00" AzureFunctionsJobHost__functionTimeout = 00:05:00
"default": "Warning" (under logging.logLevel) AzureFunctionsJobHost__logging__logLevel__default = Information
Plan Type Startup Mechanism Key Technical Detail Performance Implication
Consumption Event-driven via Scale Controller Host is instantiated on-demand. Potential for cold-start latency
Premium Event-driven + Always Ready Always-ready and pre-warmed instances eliminate cold starts; supports VNet and long-running executions Instant response with no cold starts; predictable baseline cost
Dedicated (App Service) Always On Host process continuously active; manual or rule-based scaling No cold starts; scale based on App Service plan configuration
@nadeem4
nadeem4 / azure_functions_process_model_comparison.csv
Created June 16, 2025 15:49
This CSV file provides a comparative summary of the two primary hosting models for Azure Functions: the legacy "In-Process" model and the modern "Out-of-Process" (or Isolated Worker) model. The data outlines key architectural differences between them across several characteristics, including process boundaries, fault tolerance, dependency manage…
Characteristic In-Process Model (Old) Out-of-Process Model (Modern)
Process Boundary Shared single process Separate, isolated processes
Fault Tolerance Low; a code crash can kill the Host High; the Host is protected from code crashes
Dependency Mgmt. Tightly coupled versions Decoupled; use your desired language version
Communication Direct in-memory calls (fast) Inter-process communication (slightly more overhead)
host.json Path App Setting Key
logging.logLevel.default AzureFunctionsJobHost__logging__logLevel__default
logging.logLevel.Function.MyFunction.User AzureFunctionsJobHost__logging__logLevel__Function__MyFunction__User
import logging
import logging.config
import os
LOG_DIR = 'app_logs'
if not os.path.exists(LOG_DIR):
os.makedirs(LOG_DIR)
class KeywordFilter(logging.Filter):
def __init__(self, keyword_to_allow=None, case_sensitive=True):
import logging
import logging.config
import os
LOG_DIR = 'app_logs'
if not os.path.exists(LOG_DIR):
os.makedirs(LOG_DIR)
class APIMonitoringHandler(logging.Handler):
def __init__(self, api_key, endpoint_url, failure_log_file):
@nadeem4
nadeem4 / config_log_using_dictconfig.py
Created June 12, 2025 20:10
How to configure logger using dictConfig?
import logging
import logging.config
import os
LOG_DIR = 'app_logs'
if not os.path.exists(LOG_DIR):
os.makedirs(LOG_DIR)
BASIC_LOGGING_CONFIG = {
'version': 1,
@nadeem4
nadeem4 / loggin_config_comparision.csv
Last active June 9, 2025 12:10
different method to setup logging
Method Best For
basicConfig() Small, single-file scripts and quick debugging sessions.
Programmatic Highly dynamic setups where logging behavior is determined by code at runtime.
fileConfig() Maintaining legacy applications; dictConfig is the modern standard for new projects.
dictConfig() All modern libraries, microservices, and applications requiring scalable, environment-aware logging.
We can make this file beautiful and searchable if this error is corrected: Unclosed quoted field in line 5.
"Feature","LoggerAdapter","logging.Filter"
"Primary Purpose","To provide a context-aware interface to a logger, automatically injecting predefined contextual information.","To exert fine-grained control over log records after creation but before handler processing; can add/modify data or decide if a record is processed."
"When it Acts","Before the log record is fully created by the underlying logger (its `process()` method is called first).","After a LogRecord is created by a logger, but before it is processed by a handler."
"How Context is Added","Typically injects context from its `extra` attribute (set at instantiation) into log calls made through it. Often instance-specific.","Can add context by modifying the LogRecord directly (e.g., from `contextvars`, global settings, or record attributes)."
"Modification Capabilities","Primarily adds data to the `extra` dictionary. Can modify message/kwargs if its `process()` method is overridden.","Can modify any attribute of the LogRecord (e.g., `msg`, `levelname`,