[{"content":"In Unix and Linux systems, almost everything—regular files, directories, pipes, network sockets, and character devices—is represented as a stream of bytes accessed through a file descriptor (FD).\nStandard File Descriptors By default, every new Unix process starts with three open file descriptors:\nFD Number Name Description Default Target 0 stdin Standard Input Keyboard / Stream input 1 stdout Standard Output Terminal display 2 stderr Standard Error Terminal display (unbuffered error stream) Under the Hood: Per-Process vs Kernel File Table When your process calls open() or socket(), the kernel doesn\u0026rsquo;t give user space direct access to internal memory structures. Instead:\nIt allocates a non-negative integer in your process\u0026rsquo;s File Descriptor Table (e.g., 3, 4, etc.). That entry points to the system-wide Open File Description Table in the kernel, tracking the file offset, status flags (like non-blocking), and access mode. That entry points to the file\u0026rsquo;s inode table entry on the disk. [Process FD Table] ──\u0026gt; [Kernel Open File Table] ──\u0026gt; [Inode / Device] FD 3 (stdout/pipe) Offset: 1024, Mode: Read File on disk Checking Open Descriptors for a Process You can inspect the file descriptors of any running process in Linux via /proc:\nls -l /proc/\u0026lt;PID\u0026gt;/fd This simple, unified abstraction makes redirection (\u0026gt;, 2\u0026gt;\u0026amp;1, |) in Unix shells extraordinarily clean, predictable, and composable.\n","permalink":"https://sambanamuduri.in/til/linux-file-descriptors/","summary":"A quick note on how standard file descriptors work in Unix-like systems and how the kernel tracks them.","title":"Linux: Everything Is a File (Understanding File Descriptors)"},{"content":" This is a Now page, inspired by Derek Sivers. It details what I am currently focused on, building, and exploring.\n🛠️ What I\u0026rsquo;m Building \u0026amp; Exploring Low-Level \u0026amp; Kernel Concepts: Diving into Linux kernel interfaces, system calls (epoll, memory mapping, process scheduling), and socket programming. Backend Architecture: Exploring high-throughput, low-latency microservice architectures and JVM internals. Blogging \u0026amp; Knowledge Sharing: Sharing technical learnings, debugging stories, and systems knowledge on this blog. 📚 What I\u0026rsquo;m Reading The Linux Programming Interface by Michael Kerrisk — studying low-level system calls, signals, and process APIs. Unix Network Programming, Vol 1 by W. Richard Stevens — mastering low-level networking, sockets, and multiplexing. 🎯 Current Focus Writing clean, reliable code with minimal abstractions where performance matters. Staying curious, building with intention, and avoiding the rat race. Last updated: October 2026 — Hyderabad, India\n","permalink":"https://sambanamuduri.in/now/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003eThis is a \u003ca href=\"https://nownownow.com/about\"\u003eNow page\u003c/a\u003e, inspired by Derek Sivers. It details what I am currently focused on, building, and exploring.\u003c/em\u003e\u003c/p\u003e\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch3 id=\"-what-im-building--exploring\"\u003e🛠️ What I\u0026rsquo;m Building \u0026amp; Exploring\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eLow-Level \u0026amp; Kernel Concepts:\u003c/strong\u003e Diving into Linux kernel interfaces, system calls (\u003ccode\u003eepoll\u003c/code\u003e, memory mapping, process scheduling), and socket programming.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBackend Architecture:\u003c/strong\u003e Exploring high-throughput, low-latency microservice architectures and JVM internals.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBlogging \u0026amp; Knowledge Sharing:\u003c/strong\u003e Sharing technical learnings, debugging stories, and systems knowledge on this blog.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"-what-im-reading\"\u003e📚 What I\u0026rsquo;m Reading\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cem\u003e\u003cstrong\u003eThe Linux Programming Interface\u003c/strong\u003e\u003c/em\u003e by Michael Kerrisk — studying low-level system calls, signals, and process APIs.\u003c/li\u003e\n\u003cli\u003e\u003cem\u003e\u003cstrong\u003eUnix Network Programming, Vol 1\u003c/strong\u003e\u003c/em\u003e by W. Richard Stevens — mastering low-level networking, sockets, and multiplexing.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"-current-focus\"\u003e🎯 Current Focus\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eWriting clean, reliable code with minimal abstractions where performance matters.\u003c/li\u003e\n\u003cli\u003eStaying curious, building with intention, and avoiding the rat race.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cem\u003eLast updated: October 2026 — Hyderabad, India\u003c/em\u003e\u003c/p\u003e","title":"Now"},{"content":"Here are some of the open-source projects, tools, and systems experiments I have built or am currently working on:\n🎮 TicTacToe in Java A 2-player interactive console TicTacToe game implemented in Java.\nFocus: Object-oriented design, 3x3 grid state management, turn-based input validation, and clean CLI UX. Stack: Java, JDK 21 ⚡ Linux Systems \u0026amp; Kernel Labs Hands-on explorations of low-level Unix system programming inspired by The Linux Programming Interface.\nFocus: Direct system calls, process creation (fork/exec), IPC (pipes, FIFOs), signal handling, and I/O multiplexing (epoll/select). Stack: C, Linux, POSIX APIs ☕ High-Throughput Backend Microservices Robust backend services designed for scalability, transactional reliability, and observability.\nFocus: RESTful APIs, Spring Boot microservices, database transactions, caching strategies, and GCP cloud deployments. Stack: Java, Spring Boot, PostgreSQL, Docker, GCP 🧠 NLP Reviews Sentiment Analysis Machine learning pipeline for classifying and analyzing customer sentiment from text reviews.\nFocus: Data preprocessing, tokenization, feature extraction, and sentiment classification modeling. Stack: Python, Scikit-Learn, NLTK, Pandas 📱 Health Mobile Application Mobile health application facilitating user vitals tracking, health data monitoring, and wellness management.\nFocus: User authentication, responsive mobile interface, and secure backend integration. Stack: Mobile SDKs, REST APIs 💡 Check out more experiments and repositories on my GitHub profile.\n","permalink":"https://sambanamuduri.in/projects/","summary":"\u003cp\u003eHere are some of the open-source projects, tools, and systems experiments I have built or am currently working on:\u003c/p\u003e\n\u003chr\u003e\n\u003ch3 id=\"-tictactoe-in-java\"\u003e🎮 \u003ca href=\"https://github.com/SambaNamuduri\"\u003eTicTacToe in Java\u003c/a\u003e\u003c/h3\u003e\n\u003cp\u003eA 2-player interactive console TicTacToe game implemented in Java.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFocus:\u003c/strong\u003e Object-oriented design, 3x3 grid state management, turn-based input validation, and clean CLI UX.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStack:\u003c/strong\u003e Java, JDK 21\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"-linux-systems--kernel-labs\"\u003e⚡ \u003ca href=\"https://github.com/SambaNamuduri\"\u003eLinux Systems \u0026amp; Kernel Labs\u003c/a\u003e\u003c/h3\u003e\n\u003cp\u003eHands-on explorations of low-level Unix system programming inspired by \u003cem\u003eThe Linux Programming Interface\u003c/em\u003e.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFocus:\u003c/strong\u003e Direct system calls, process creation (\u003ccode\u003efork\u003c/code\u003e/\u003ccode\u003eexec\u003c/code\u003e), IPC (pipes, FIFOs), signal handling, and I/O multiplexing (\u003ccode\u003eepoll\u003c/code\u003e/\u003ccode\u003eselect\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStack:\u003c/strong\u003e C, Linux, POSIX APIs\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"-high-throughput-backend-microservices\"\u003e☕ \u003ca href=\"https://github.com/SambaNamuduri\"\u003eHigh-Throughput Backend Microservices\u003c/a\u003e\u003c/h3\u003e\n\u003cp\u003eRobust backend services designed for scalability, transactional reliability, and observability.\u003c/p\u003e","title":"Projects"},{"content":"Just last week, we faced a sudden production failure in one of our core serverless data ingestion pipelines.\nThe pipeline runs on AWS Lambda with the Python 3.12 runtime. Its responsibility is straightforward: securely fetch an encrypted file from an external source, decrypt it, parse its hierarchical data structures (specifically large Excel spreadsheets with nested object trees), and stream the extracted records to downstream stores.\nWe had provisioned the Lambda with 1 vCPU of compute power (~1,769 MB of RAM)—what we initially assumed was generous headroom, bordering on \u0026ldquo;overkill.\u0026rdquo; Yet, during a batch run, the function abruptly died with an unceremonious Out-of-Memory (OOM) crash, leaving files half-processed and transactions incomplete.\nHere is the breakdown of why our memory ballooned, how we isolated the bottleneck, and why switching to disk-backed ephemeral storage resolved the issue.\n1. The Architecture \u0026amp; The Pipeline The ingestion flow handles sensitive files that must be decrypted and validated on the fly:\n[External Source / S3] │ (Encrypted Ciphertext) ▼ [AWS Lambda (Python 3.12)] ├── 1. Fetch KMS / STS Secrets ├── 2. Decrypt Payload ├── 3. Parse Document Trees (Excel / XML Sheets) └── 4. OpenTelemetry Spans \u0026amp; S3 Upload Before processing, the function executes peripheral tasks:\nAssumes roles via AWS STS and fetches encryption keys. Instruments spans using OpenTelemetry for end-to-end tracing. Interacts with Amazon S3 using Boto3. Each of these peripheral tasks consumes negligible CPU and memory (typically under 20–30 MB). So why were we exhausting over 1.7 GB of memory?\n2. The Symptoms: Sudden Death in Production During execution with larger files (30MB–80MB .xlsx spreadsheets), the Lambda invocation did not fail gracefully with an application-level exception. Instead, AWS CloudWatch reported:\nREPORT RequestId: 8e4b3c92-11a5-4f7e-bc91-23d91f28014e Duration: 18420.12 ms Billed Duration: 18421 ms Memory Size: 1769 MB Max Memory Used: 1769 MB Status: error Error: Runtime.ExitError (Signal: killed) The Linux kernel\u0026rsquo;s Out-Of-Memory killer had sent SIGKILL to the Python process. The file execution was aborted mid-stream, resulting in missing records and inconsistent state downstream.\n3. The Investigation \u0026amp; Root Cause Ruling Out the Red Herrings We initially checked:\nOpenTelemetry Telemetry Buffers: Was the OTel SDK buffering too many spans? No—span batching was flushed frequently and used less than 15 MB. Boto3 \u0026amp; STS Client Leaks: Were connection pools leaking memory? No—connections were properly reused. The Real Culprit: In-Memory Buffering + DOM Tree Amplification Looking closely at the ingestion code, we discovered that the entire pipeline was being operated strictly in RAM:\n# The Flawed In-Memory Approach: response = s3_client.get_object(Bucket=bucket, Key=key) ciphertext_bytes = response[\u0026#39;Body\u0026#39;].read() # Stored in RAM (e.g. 60 MB) # In-memory decryption buffer: decrypted_stream = io.BytesIO() cipher.decrypt(ciphertext_bytes, decrypted_stream) plaintext_bytes = decrypted_stream.getvalue() # Another 60 MB in RAM! # In-memory Excel parsing: workbook = openpyxl.load_workbook(io.BytesIO(plaintext_bytes)) Notice what happened here:\nDouble Buffering: At any given moment, the ciphertext byte string, the decryption output buffer, and the plaintext byte string were coexisting simultaneously in Python\u0026rsquo;s heap.\nThe \u0026ldquo;Excel XML Expansion\u0026rdquo; Multiplier: An .xlsx file is actually a compressed ZIP archive containing raw XML files. A 50 MB compressed spreadsheet can expand to 400 MB–800 MB of raw XML.\nPython Object Overhead: When a library like openpyxl parses an XML document into Python objects (rows, cells, styles, formulas), each cell is represented as a full Python PyObject. In Python, a single integer or string has significant memory overhead compared to raw C primitives.\nA 50 MB file in memory rapidly expanded into 1.8+ GB of active Python heap memory, triggering an instant OOM crash.\n[Compressed File: 50 MB] │ ▼ (Decryption in RAM) [Plaintext Bytes: 50 MB] │ ▼ (Unzipped XML: 500 MB) [Python DOM Objects in Heap: \u0026gt; 1.8 GB] ──\u0026gt; 🔥 OOM KILL 4. The Fix: Offloading from RAM to Ephemeral /tmp Storage Instead of treating Lambda\u0026rsquo;s expensive memory as a hard drive, we realized that AWS Lambda provides ephemeral disk storage (/tmp)—ranging from 512 MB up to 10 GB of high-speed NVMe storage.\nRather than buffering byte streams in memory, we redesigned the pipeline to stream directly to disk and parse in read-only chunks.\nStep 1: Stream Decryption Directly to Disk We replaced io.BytesIO with tempfile.NamedTemporaryFile backed by Lambda\u0026rsquo;s /tmp directory:\nimport tempfile import openpyxl def process_encrypted_file(s3_client, bucket, key): # Create temporary files on Lambda\u0026#39;s local NVMe disk with tempfile.NamedTemporaryFile(dir=\u0026#34;/tmp\u0026#34;, delete=True) as enc_file, \\ tempfile.NamedTemporaryFile(dir=\u0026#34;/tmp\u0026#34;, delete=True) as dec_file: # 1. Stream download to disk in chunks (keeps RAM flat) s3_client.download_fileobj(bucket, key, enc_file) enc_file.flush() enc_file.seek(0) # 2. Decrypt in streaming chunks from file to file decrypt_file_stream(enc_file, dec_file) dec_file.flush() dec_file.seek(0) # 3. Stream-parse without loading the entire DOM into memory workbook = openpyxl.load_workbook( filename=dec_file.name, read_only=True, # Stream parser: does NOT load all cells at once data_only=True ) for sheet in workbook: for row in sheet.iter_rows(values_only=True): process_row(row) workbook.close() Step 2: Read-Only Streaming Mode By passing read_only=True to load_workbook, openpyxl switches from building a massive in-memory DOM tree to an iterative XML parser (iterparse). It reads and yields rows one by one, dropping processed rows from memory immediately.\n5. Results \u0026amp; Metrics Metric In-Memory (Before) Disk-Backed Streaming (After) Peak Memory Consumption \u0026gt; 1,769 MB (OOM Crash) ~140 MB (Flat \u0026amp; Predictable) Max Processable File Size ~40 MB 500 MB+ Failure Rate ~18% on large batches 0% Lambda Memory Sizing Required 2 GB+ (failing) Can safely run at 512 MB (Cost Savings!) 6. Key Takeaways Don\u0026rsquo;t Treat RAM as a File System: In serverless environments, RAM is the most expensive resource. If you\u0026rsquo;re holding full payloads in BytesIO buffers, you\u0026rsquo;re paying for memory you don\u0026rsquo;t need. Beware the Spreadsheet Amplification Factor: Spreadsheets and XML documents are deceptively compressed on disk. In-memory object trees can expand by 10x to 30x the file\u0026rsquo;s raw size. Lambda /tmp Storage is Fast NVMe: Lambda\u0026rsquo;s ephemeral storage is local, fast, and gives you at least 512 MB for free (expandable up to 10 GB). Use it to spool, decrypt, and parse large binary streams. Use Iterative Stream Parsers: Whenever parsing tabular or structured files, prefer streaming APIs (read_only=True, SAX, or iterparse) over loading the full DOM tree into memory. ","permalink":"https://sambanamuduri.in/blog/debugging-story-october/","summary":"How a file decryption and spreadsheet parsing pipeline in Python 3.12 triggered sudden Out-Of-Memory (OOM) crashes in AWS Lambda, and how leveraging ephemeral /tmp storage fixed our production pipeline.","title":"Debugging AWS Lambda OOM: Why In-Memory File Decryption Blew Up Our Python Runtime"},{"content":"Back in July, we encountered a tricky observability bug while running an asynchronous compute pipeline inside AWS Lambda processing data from Amazon S3.\nWe had instrumented our workload with OpenTelemetry (OTel) to gain granular insights into execution bottlenecks, network latency, and compute time. But when we opened our tracing dashboard, instead of a clean, cohesive flamegraph showing our execution flow, we were greeted with total chaos: span explosion, orphaned traces, and completely disconnected parent-child spans.\nHere is what went wrong, why our concurrency model broke OpenTelemetry\u0026rsquo;s default behavior, and how we solved it using distributed tracing context propagation.\n1. Context \u0026amp; Architecture Our serverless pipeline processes large objects retrieved from S3:\nLambda Invocation: An S3 object notification triggers the Lambda handler on the main runtime thread. Concurrent Compute: Because each S3 payload contains hundreds of independent tasks, the handler dispatches these compute tasks across a pool of background worker threads to leverage multi-core Lambda compute efficiently. Task Completion \u0026amp; Sinks: Each worker performs its computation, writes results, and signals completion. [S3 Event] ──\u0026gt; [Lambda Handler (Main Thread)] │ ├── Dispatch ──\u0026gt; [Worker Thread 1: Process Task A] ├── Dispatch ──\u0026gt; [Worker Thread 2: Process Task B] └── Dispatch ──\u0026gt; [Worker Thread 3: Process Task C] To monitor performance, the Lambda handler initiated a root trace (lambda-s3-compute), and each worker task was supposed to create a child span (process-task) linked directly to that parent.\n2. The Symptoms: The \u0026ldquo;Broken Trace\u0026rdquo; Mystery When inspecting traces in our telemetry backend (Jaeger / Honeycomb), two bizarre problems showed up:\nIssue A: Disconnected Orphan Traces Instead of seeing one single trace ID containing the root handler span and multiple nested child spans, we saw dozens of separate root traces:\nWHAT WE EXPECTED: └── [Trace ID: 4bf92f3577b34da6a3ce929d0e0e4736] └── lambda-s3-compute (Parent Span) ├── process-task (Worker 1) ├── process-task (Worker 2) └── process-task (Worker 3) WHAT ACTUALLY HAPPENED: ├── [Trace ID: 4bf92f3577b34da6] -\u0026gt; lambda-s3-compute (Orphaned Parent) ├── [Trace ID: 8a1b92c431d87e01] -\u0026gt; process-task (Worker 1 as a new Root!) ├── [Trace ID: 5f2a1b9c84e12019] -\u0026gt; process-task (Worker 2 as a new Root!) └── [Trace ID: 3e9d81a4b5c77204] -\u0026gt; process-task (Worker 3 as a new Root!) Issue B: Span Explosion \u0026amp; Redundant Telemetry Because child tasks were not tethered to their parent, tasks that spawned sub-tasks or HTTP requests generated runaway spans with distinct IDs. Telemetry ingestion costs spiked, and searching for the trace of a single S3 file execution was virtually impossible because none of the spans shared a common trace context.\n3. The Investigation \u0026amp; Root Cause Where was the context getting lost? In the main Lambda handler, the span was active:\n// Main handler thread Tracer tracer = openTelemetry.getTracer(\u0026#34;s3-compute\u0026#34;); Span parentSpan = tracer.spanBuilder(\u0026#34;lambda-s3-compute\u0026#34;).startSpan(); try (Scope scope = parentSpan.makeCurrent()) { // Context is active HERE on the main thread dispatchTasksConcurrently(tasks); } finally { parentSpan.end(); } Inside the worker threads, we were starting child spans like this:\n// Worker thread (inside ExecutorService / Runnable) public void run() { // We expected OTel to automatically know the parent! Span childSpan = tracer.spanBuilder(\u0026#34;process-task\u0026#34;).startSpan(); try { processItem(); } finally { childSpan.end(); } } The \u0026ldquo;Aha!\u0026rdquo; Moment: Thread Boundaries Break ThreadLocal By default in most OpenTelemetry SDKs (such as Java and Python), the active trace context is stored in ThreadLocal memory.\nWhen parentSpan.makeCurrent() is called, the trace context is bound strictly to the Main Thread. When worker tasks are dispatched to an ExecutorService or worker threads, the child threads do not inherit the parent thread\u0026rsquo;s ThreadLocal context. When tracer.spanBuilder(\u0026quot;process-task\u0026quot;).startSpan() executes inside the worker thread, OpenTelemetry inspects Context.current(), finds nothing, and assumes: \u0026ldquo;There is no active span on this thread. I must create a brand-new Trace ID and treat this as a brand-new Root Span!\u0026rdquo;\nThis explained why all our worker spans were severed from the parent and generating arbitrary new trace IDs!\n4. The Fix: Explicit Context Propagation Across Threads To fix this, we applied the fundamental rule of distributed tracing: When crossing an execution boundary (network or thread), you must explicitly propagate the Context.\nThe Solution: Wrapping Runnables with OTel Context OpenTelemetry provides built-in utilities to capture the active context from the parent thread and attach it to the worker execution.\nBefore (Broken): // Parent thread dispatches without context: executorService.submit(() -\u0026gt; { // Context is NULL here! doWork(); }); After (Fixed with Context.current().wrap()): // 1. Capture the current context on the main thread Context parentContext = Context.current(); for (Task task : tasks) { // 2. Wrap the Runnable so it carries the parent context into the worker thread Runnable wrappedTask = parentContext.wrap(() -\u0026gt; { // 3. Inside worker: Context is now restored! Span childSpan = tracer.spanBuilder(\u0026#34;process-task\u0026#34;) .startSpan(); try (Scope scope = childSpan.makeCurrent()) { executeTask(task); } finally { childSpan.end(); } }); executorService.submit(wrappedTask); } Alternative: Using OpenTelemetry Context in Custom Handlers If you\u0026rsquo;re passing state objects between threads, you can also pass the parent Context explicitly:\npublic void processInWorker(Context parentContext, Task task) { // Explicitly bind the parent context to the span builder Span childSpan = tracer.spanBuilder(\u0026#34;process-task\u0026#34;) .setParent(parentContext) .startSpan(); try (Scope scope = childSpan.makeCurrent()) { execute(task); } finally { childSpan.end(); } } 5. The Outcome Once we deployed the fix:\nUnified Traces: Every S3 invocation produced exactly one Trace ID. Proper Tree Hierarchy: All worker threads appeared as neat, concurrent parallel child bars under the main handler span in the flamegraph. Accurate Bottleneck Detection: We could instantly identify which specific S3 task worker was bottlenecked on I/O vs. compute. Clean Telemetry Bills: Zero runaway root spans or detached noise. 6. Key Takeaways ThreadLocal Never Crosses Thread Pools Automatically: Whenever you use ExecutorService, asynchronous callbacks, or worker pools, never assume the logging or tracing context will travel with the task. Use Context.current().wrap(): OpenTelemetry\u0026rsquo;s Context.wrap() is the cleanest, idiomatic way to pass trace propagation across concurrency boundaries. Always End Spans in finally Blocks: Ensure span.end() is guaranteed to execute, even on unhandled exceptions, to prevent memory leaks and dangling spans. Inspect Flamegraphs Early: Don\u0026rsquo;t just test if telemetry is arriving; verify that the Trace ID and Parent Span ID relationships are mathematically connected. ","permalink":"https://sambanamuduri.in/blog/debugging-story-july/","summary":"How a concurrent compute workload in AWS Lambda caused span explosion and disconnected traces in OpenTelemetry, and how we solved it using distributed context propagation.","title":"Debugging OpenTelemetry in AWS Lambda: Fixing Broken Traces Across Worker Threads"},{"content":"ANSI C and Object Oriented Programming C++ Programming by Balaguruswamy One of the foundational books in my programming journey has been \u0026ldquo;C and C++ Programming\u0026rdquo; by Balaguruswamy has provided me with a understanding of the C and C++ programming languages.\nJava The Complete Reference by Herbert Schildt Another essential book in my collection is \u0026ldquo;Java\u0026rdquo; by Herbert Schildt. This book has been a go-to reference for me as I\u0026rsquo;ve delved into the world of Java programming. From the basics of the language to its more advanced features, this book has been a reliable companion in my Java learning journey.\nUnix Programming Environment by Brian Kernighan Exploring the Unix operating system has been a crucial part of my programming education, and \u0026ldquo;Unix Programming Environment\u0026rdquo; by Brian Kernighan has been an indispensable resource. This book has provided me with a deep understanding of the Unix shell, utilities, and programming tools.\nLinux Interface by Michael Kerrisk Recently,I\u0026rsquo;ve been reading \u0026ldquo;Linux Interface\u0026rdquo; by Michael Kerrisk.It\u0026rsquo;s system calls, and the low-level programming interfaces that are super cool and interesting. It\u0026rsquo;s really huge book. Oops..\nUnix Network Programming, Volume 1 by W. Richard Stevens As I\u0026rsquo;ve delved deeper into the world of programming, I\u0026rsquo;ve also been exploring the realm of network programming. \u0026ldquo;Unix Network Programming, Volume 1\u0026rdquo; by W. Richard Stevens.\nSpring in Action Finally, as I\u0026rsquo;ve explored the world of Java frameworks,\u0026ldquo;Spring in Action\u0026rdquo; has been a go-to reference helped me understand the Spring framework, its core concepts, and how to leverage its powerful features to build modern Java applications.\n","permalink":"https://sambanamuduri.in/books/","summary":"\u003ch4 id=\"ansi-c-and-object-oriented-programming-c-programming-by-balaguruswamy\"\u003eANSI C and Object Oriented Programming C++ Programming by Balaguruswamy\u003c/h4\u003e\n\u003cp\u003eOne of the foundational books in my programming journey has been \u0026ldquo;C and C++ Programming\u0026rdquo; by Balaguruswamy has provided me with a understanding of the C and C++ programming languages.\u003c/p\u003e\n\u003ch4 id=\"java-the-complete-reference-by-herbert-schildt\"\u003eJava The Complete Reference by Herbert Schildt\u003c/h4\u003e\n\u003cp\u003eAnother essential book in my collection is \u0026ldquo;Java\u0026rdquo; by Herbert Schildt. This book has been a go-to reference for me as I\u0026rsquo;ve delved into the world of Java programming. From the basics of the language to its more advanced features, this book has been a reliable companion in my Java learning journey.\u003c/p\u003e","title":"My Journey Through Programming Books"},{"content":"Hey! My name is Samba. I write my system and backend programming, and I have a background in backend development with Java, Spring, and other JVM technologies, along with experience in Google Cloud Platform (GCP). However, my true passion lies in system and network programming. I love experimenting with the kernel and often find myself wishing I had discovered this interest earlier—while also Googling how to exit Vim and grappling with my feelings about JavaScript!\nIn my previous roles, I focused on automating my work processes, which ironically made me lazier but ultimately led me to work harder to achieve that goal. I believe abstraction is a key trend in our field. Computer Science is amazing; it has empowered me to write this and for you to read it!\nThe views expressed here are my own and are not influenced by any language models.\n","permalink":"https://sambanamuduri.in/aboutme/","summary":"\u003cp\u003eHey! My name is Samba. I write my system and backend programming, and I have a background in backend development with Java, Spring, and other JVM technologies, along with experience in Google Cloud Platform (GCP). However, my true passion lies in system and network programming. I love experimenting with the kernel and often find myself wishing I had discovered this interest earlier—while also Googling how to exit Vim and grappling with my feelings about JavaScript!\u003c/p\u003e","title":"About Me"}]