Think Different

                                                                  Generated by Gemini For the last 28 years and more I have been working as Solutions Engineer / Solutions Architect (SE/SA) + Professional Services / Implementation Engineer + Customer-Facing Software Engineer together combined. Various companies I have worked on pre-sales technical scoping & integration design resembled SE/SA work or/and FDSEs inherit full production-grade coding responsibilities and Enterprise deployment & customisation tasks. From understanding requirements from internal domain expert like here in BNY or from pre sales team of a SaaS or AI company. Never thought about what exactly my role or position is. Responsibilities always came first. Despite being a hard-core computer science student with vast fundamental knowledge, including ...

Here are the key lessons from Uber's architectural redesigns for risk management, synthesized from their engineering blogs and public case studies. 🚦 Lesson 1: Orchestrate Risk Across Services, Not Just Within Them The first major lesson came from addressing the "blast radius" problem. In a monorepo architecture, a single bad commit could potentially break thousands of services at once . - The Problem: Traditional safety checks (pre-commit tests, per-service health metrics) were insufficient. If a change passed initial tests but failed in production, automated deployment pipelines could rapidly propagate the failure to hundreds of critical services before anyone noticed . - The Solution: Uber introduced a cross-cutting service deployment orchestration layer. This system acts as a global gatekeeper, coordinating rollouts across all services affected by a single commit . - How It Works:     - Service Tiering: Services are classified into tiers from 0 (most critical, e.g., ...

  meta ai The philosophy of combining Open-Source Software (OSS) like Kubernetes and Docker with proprietary offerings like Azure Cosmos DB, while often pragmatic, presents several potential issues, particularly for Azure users: 1. Vendor Lock-in (especially with proprietary services like Cosmos DB): Dependency on a single vendor: When you adopt a proprietary service like Cosmos DB, you become heavily dependent on Microsoft for its functionality, updates, and support. This makes it challenging and costly to switch to another database or cloud provider if your needs change, if Microsoft alters its pricing or features unfavorably, or if you simply want to leverage a different technology. Proprietary APIs and data formats: Cosmos DB uses its own APIs and internal data structures, which are not directly transferable to other databases. Migrating data and refactoring application code built around these proprietary interfaces can be a massive undertaking, incurring significant time a...

                                                                           meta ai Almost all companies today rely on LinkedIn to extract candidate profiles during hiring or onboarding. However, despite widespread use, even large enterprises frequently fail to extract complete and accurate profile data. The result is broken or partial imports, dozens of mismatches and formatting errors, and missing sections like certifications, experience, or education. This often forces candidates to manually re-enter or correct the information—costing them time, creating frustration, and negatively impacting their experience. To read LinkedIn profile details (including licenses and certifications ) after authorization, follow this short and structured approach: ✅ Prerequisites LinkedIn Developer Account A reg...