Tectalks

LaGuardia, March 22: When Every Layer of Defence Had a Hole

Fri, 27 Mar 2026 00:00:00 +0000

On the night of March 22, I was following live ATC feeds when Air Canada Express Flight 8646 dropped off the radar at LaGuardia. A CRJ-900LR, registration C-GNJZ, operated by Jazz Aviation, had struck a Port Authority ARFF fire truck while landing on Runway 4 at 11:45 PM. Both pilots — First Officer Antoine Forest, 30, and Captain MacKenzie Gunther, 38 — were killed. Forty-one others were hospitalised.

As a pilot, this one hits differently. Runway incursions are something you think about every time you taxi at a towered field. You trust the system — the controllers, the lights, the radar. What the NTSB preliminary findings reveal is that on this night, the system failed at every level. Not one thing went wrong. Everything went wrong.

No transponder on the truck

The Port Authority ARFF truck that crossed Runway 4 did not have a transponder. That is the most basic piece of equipment for surface tracking. Without it, the truck was invisible to the airport’s automated systems. You cannot track what does not broadcast. This is not a sophisticated failure — it is an equipment gap that should not exist on an active airfield in 2026.

ASDE-X saw nothing

LaGuardia has ASDE-X, the FAA’s surface detection system designed specifically to prevent runway incursions. It should have flagged the conflict. It didn’t. The FAA tech centre’s analysis, read aloud by NTSB Chair Jennifer Homendy, explained that ASDE-X did not generate an alert “due to the close proximity of vehicles merging and unmerging near the runway, resulting in the inability to create a track of high confidence.”

The system got confused by vehicles clustering near the runway and lost the track. The one piece of automation that existed to catch this — could not see it.

The lights were working

The runway status lights — the ones embedded in the pavement that turn red when a runway is active — were confirmed operational. They should have provided a clear, final warning to the truck crew. Whether the crew saw the lights and why they proceeded is still under investigation. But the lights did their job. Something between the lights and the decision to cross did not.

Conflicting clearances

Two minutes and seventeen seconds before impact, the tower cleared Flight 8646 to land on Runway 4. Twenty seconds before impact, the same tower cleared the fire truck to cross that runway. Both clearances were active at the same time. Nine seconds before impact, the tower issued a stop command to the truck. It was far too late.

If you have ever been on short final at approach speed, you know what twenty seconds means. You are committed. There is no go-around window when the conflict appears nine seconds out.

Two controllers, four positions

Two controllers were staffing the tower that night. Standard midnight shift configuration at LaGuardia — each controller working two positions. There is conflicting information about who was actually performing ground control duties. The NTSB is still sorting that out.

Homendy noted that controllers themselves have been raising this as a concern: “Our air traffic control team has stated this is a problem, that this is a concern for them for years.” She also pointed out that the systems they are working with have not kept pace: “Controllers should have all the info and tools they need to do their job. This is 2026.”

Two people doing four jobs, at midnight, during an active emergency. That is what the staffing picture looked like.

The emergency that started it all

The truck was not on the runway for a routine reposition. It had been dispatched to respond to United Airlines Flight 2384, a 737 MAX 8 bound for Chicago O’Hare. That aircraft had aborted its takeoff twice due to an anti-ice warning light. The crew then reported a foul smell in the cabin, flight attendants became ill, and an emergency was declared at 11:31 PM.

So the controllers were managing an active aircraft emergency, dispatching ARFF vehicles, and simultaneously running landing traffic on the same runway — with half the normal staffing. The very emergency that put the truck on Runway 4 was consuming the attention of the people who should have been protecting it.

Swiss cheese

James Reason’s Swiss cheese model describes how accidents happen when the holes in multiple layers of defence line up. A transponder on the truck and ASDE-X builds a reliable track. A reliable track and the system generates an alert. An alert and the controller catches the conflict before issuing clearance. The truck crew heeds the runway status lights and holds short. A fully staffed tower and someone catches the error with enough time to act. No concurrent emergency and the truck is never there in the first place.

On this night, every layer had a hole, and they all aligned.

Homendy put it plainly: “We rarely, if ever, investigate an accident where it was one failure. Our aviation system is safe because there are multiple — multiple — layers of defense built in to prevent an accident. So when something went wrong, that means many, many things went wrong.”

The investigation is ongoing. But the preliminary picture is already clear — this was not a single mistake. It was an entire system of defences failing together, with twenty seconds of margin between routine operations and a fatal accident.

Delhi to Vienna, the Long Way Round

Mon, 09 Mar 2026 12:00:00 +0100

When conflict escalated across the Middle East in late February 2026, airspace closures followed rapidly. NOTAMs were issued, but at short notice, and the scope kept expanding. Within days, large swathes of Middle Eastern airspace — not just Iran, but multiple FIRs across the region — were closed to commercial overflights. Hundreds of daily flights between South Asia and Europe that normally transit these corridors had to find alternate routing. As a pilot, this is the kind of scenario you train for in theory but rarely witness at this scale. As an engineer, it is a dataset waiting to be captured.

I started tracking Air India flight AI153, a Boeing 787-8 operating Delhi to Vienna, using publicly available ADS-B data from FlightAware’s AeroAPI. The goal was straightforward: capture the actual tracks flown before, during, and after the closures, and study how airline operations adapted.

The normal route

On February 26, two days before the conflict began, AI153 flew what had been its standard routing for years. Out of Delhi heading southwest through Rajasthan, down to the Makran coast of Pakistan, then turning north through the Oman-UAE corridor into the Persian Gulf region. From there, northwest across Iraq and into Turkish airspace, then through the Balkans into Vienna. About 755 ADS-B position reports trace a clean, efficient path — the kind of routing you would expect on a mature long-haul sector.

The aircraft reached a northernmost latitude of around 48°N at Vienna, with the route’s critical transit through the Gulf region clearly visible around 29°N, 48°E. This corridor through the Middle East is the backbone of traffic between South Asia and Europe.

February 28 — airborne when it started

The February 28 flight is where the data gets interesting. War broke out that day, and AI153 was already airborne. The track shows the initial departure from Delhi following the same familiar southwest heading through Rajasthan and down to the Pakistani coast. The first half of the route looks identical to the February 26 flight.

But then the divergence. Instead of turning north through the Gulf corridor, the aircraft stayed south. At around 22°N latitude, it continued westward across the full width of the Arabian Peninsula, maintaining a low latitude all the way from 60°E to 38°E. It then turned north up the Red Sea, transited Egypt, crossed the Mediterranean, and worked its way through the Balkans into Vienna from the southeast.

736 ADS-B points tell the story of a flight that started on one routing and finished on another. Whether the crew received updated routing before departure or were re-cleared en route, the track captures the exact moment an airline’s operational planning collided with a changing geopolitical reality.

March 3 — the new normal

By March 3, the closures were well established and there was no ambiguity. AI153 departed Delhi heading southwest and committed to the southern detour from the start. Across Rajasthan, down to the Makran coast, westward across Arabia at low latitude, up the Red Sea, through Egypt, across the Mediterranean, through the Balkans, and into Vienna. 798 position reports trace what had become the standard alternate routing.

The numbers tell a clear story. What was roughly 5,800 km through the Middle Eastern corridor became approximately 7,600 km via the southern route. About 7 hours became about 9. On a 787-8, that is somewhere between 8 and 12 tonnes of additional jet fuel — per flight, per day.

Three tracks, one picture

Overlaying these three tracks on a map makes the operational impact immediately visible. The February 26 route arcs north through the Gulf and Turkey. The February 28 route starts the same way but bends south mid-journey. The March 3 route commits to the southern detour from departure. Three flights, three weeks, and you can see an airline’s entire operational response to an airspace closure in the shape of the lines.

The Middle Eastern corridor does not just serve Indian carriers going to Europe. It handles traffic from Southeast Asia, East Africa, and the Gulf states. When it closes, the alternate routes through southern Arabian airspace and Egyptian corridors absorb the overflow, creating congestion in airspaces not designed for that volume.

Why ADS-B matters here

To be clear — by March 3, none of this was a surprise. The airspace closures were known, NOTAMs were published, and airlines had already updated their flight plans. ADS-B data did not reveal something the industry did not already know.

What ADS-B data does offer is a precise, independently verifiable record of how airlines actually responded. Official NOTAMs tell you what airspace is closed. Airline schedules tell you what was planned. But ADS-B tracks show you what actually happened — the exact routing, the fuel-burning detours, the convergence of traffic onto alternate corridors. It is the ground truth.

I built a lightweight tracking tool using Python and Leaflet to capture and visualise these tracks day over day. No dependencies beyond the standard library. The AeroAPI integration is interactive and manually triggered to keep API costs controlled — 2 calls per track fetch, with a daily budget cap. Each day’s track gets injected into a comparison map, so routing changes over time become immediately visible.

What this is really about

This is not about one flight or one airline. It is about how quickly operational reality shifts when geopolitics changes the map, and how open data lets us observe and document those shifts precisely. Airlines are making significant routing decisions daily — decisions with real fuel burn, schedule, and crew implications — and the evidence is sitting in publicly available ADS-B feeds for anyone paying attention.

The intersection of aviation operations and data engineering is where I find the most interesting problems. This project sits exactly there.

The Hands-On-the-Yoke Era of AI: From General Aviation to LLM Ops

Mon, 19 Jan 2026 00:00:00 +0000

I’ve spent most of my flying time in General Aviation (GA), where the connection between the pilot and the machine is direct. In a small plane, you feel the thermals through the yoke, you hear the engine’s rhythm change with the mixture, and you are constantly adjusting for the environment.

It is a stark contrast to the world of heavy commercial jets. In those cockpits, it’s often said the autopilot handles the flight surfaces for 99% of the journey. In that environment, the pilot has evolved into a Systems Manager—monitoring the automation rather than hand-flying the aircraft.

In the tech world, we’ve spent the last decade trying to reach that “99% Autopilot” state with DevOps and SRE. We built CI/CD pipelines and infrastructure as code to make our systems “set-and-forget.” But as I’ve moved deeper into LLM Ops, I’ve realized that we’ve moved back into the cockpit of a GA aircraft.

The Return of Non-Determinism

In traditional software, we expect a specific input to always produce the same output. It’s like a mechanical linkage: you move the lever, and the flap moves exactly ten degrees.

Large Language Models (LLMs) aren’t like that. They are probabilistic engines. Managing them in production feels less like managing a server and more like flying a landing pattern in a gusty crosswind. The “atmosphere” (the prompt context, the model temperature, and the retrieval data) is always shifting.

Navigating the “Drift”

In GA, if you take your hands off the controls in turbulent air, the plane will eventually drift off course. You have to make constant, subtle micro-corrections to stay on the centerline.

This is exactly what we do in LLM Ops through Evaluations (Evals). Because LLMs are non-deterministic, we can’t rely on a simple “Pass/Fail” unit test. We have to monitor for:

Model Drift: Is the model becoming less accurate over time?
Hallucinations: Has the model “lost situational awareness” and started generating false data?
Latency: Is the “engine” struggling under the load of complex reasoning?

Prompt Engineering as Trim Tabs

In a small plane, you use “trim” to relieve the pressure on the controls so the plane flies level without constant physical effort. You aren’t redesigning the wing; you are just adjusting the surfaces to match the current conditions.

I see Prompt Engineering as the trim tabs of AI. We aren’t necessarily fine-tuning the base model every day. Instead, we are making micro-adjustments to the system instructions to balance the output. If the model is leaning too far into “creative” territory when we need “factual,” we adjust the trim to bring it back to a level flight path.

The Pilot in Command (PIC)

Modern cloud computing—especially Serverless—often feels like it’s taking the “pilot” out of the loop. But as any GA pilot knows, no matter how much technology you have in the panel, the human in the loop is ultimately responsible for the outcome.

In the age of AI, we cannot abdicate our responsibility to the model. We must understand the “physics” of how these models work. Whether I’m debugging a Go-based inference pipeline or performing a pre-flight walkaround, the goal is the same: building a deep understanding of the systems we rely on so that when the “weather” gets rough, we know exactly how to take manual control.

Is your AI on autopilot, or are you still hand-flying the mission?

AWS Lambda: The Serverless Compute Service

Mon, 20 Mar 2023 13:03:17 +0100

In the world of cloud computing, the concept of serverless computing has gained a lot of attention in recent years. Serverless computing allows developers to focus on writing code instead of managing infrastructure. One of the most popular serverless compute services is AWS Lambda, which is offered by Amazon Web Services.

AWS Lambda is a compute service that lets you run code without provisioning or managing servers. With Lambda, you simply upload your code and AWS takes care of everything else, including scaling, availability, and security. Lambda works by executing code in response to certain events, such as an HTTP request, a database change, or a file upload.

One of the key benefits of AWS Lambda is that you only pay for the compute time that your code actually uses. This means that you can run your code without having to worry about the underlying infrastructure or the cost of idle resources. AWS Lambda also provides automatic scaling, so your code can handle large spikes in traffic without any additional effort on your part.

AWS Lambda supports a wide range of programming languages, including Python, Node.js, Java, C#, and Go, among others. This allows you to choose the programming language that you are most comfortable with, and that best suits your application’s requirements.

To get started with AWS Lambda, you first need to create a Lambda function. A Lambda function is a piece of code that runs in response to an event. You can create a Lambda function using the AWS Management Console, AWS CLI, or AWS SDKs. Once you have created a Lambda function, you can configure it to trigger in response to various events, such as API Gateway requests, S3 bucket uploads, or AWS CloudFormation stack updates.

AWS Lambda is often used for building serverless applications, which are applications that rely on third-party services to manage the backend infrastructure. Serverless applications can be highly scalable, cost-effective, and easy to maintain, since you don’t have to worry about managing the underlying infrastructure yourself.

Latest Features of AWS Lambda

Lambda SnapStart: Lambda SnapStart accelerates application performance by utilizing a single pre-initialized snapshot to resume multiple execution environments.
Lambda Function URLs: Enables you to add HTTPS endpoints to any Lambda function. Additionally, it allows optional configuration of Cross-Origin Resource Sharing (CORS) headers.
Provisioned Concurrency: Allows you to ensure that a certain number of functions are running and available to respond to requests at all times. This helps to reduce cold starts and improve the overall performance of your Lambda functions.
Custom Runtimes: Allows you to use any programming language or runtime that can run on Linux. This means you can use languages like Rust, Swift, or even COBOL to write your Lambda functions.
Container Image Support: Allows you to use your own custom runtime, operating system, and dependencies. This makes it easier to migrate existing applications to Lambda and enables greater customization and control over the runtime environment.
Extensions: AWS Lambda Extensions are a new way to easily integrate Lambda with third-party tools and services. Extensions can be used to instrument and monitor Lambda functions, add security and compliance controls, or integrate with logging and debugging tools.

Overall, AWS Lambda is a powerful tool for building scalable, event-driven applications that can be run without worrying about infrastructure management. With its pay-per-use pricing model, automatic scaling, and support for multiple programming languages, AWS Lambda is an ideal choice for developers looking to build serverless applications.

Looking Back 20 Years

Sun, 19 Mar 2023 15:54:53 +0100

I still remember the day when I first started my career as a computer hardware support engineer. It was two decades ago, and technology was quite different back then. The world was not yet fully digital, and the internet was still in its early stages. However, I was determined to make a career out of my love for computers and technology.

As a computer hardware support engineer, my primary role was to provide technical support to users who were experiencing issues with their computer hardware. I worked for a company that sold computers and peripherals, and my job involved troubleshooting, repairing, and maintaining computer systems.

I was always fascinated by the workings of computers and how they functioned. I enjoyed the challenge of diagnosing and fixing hardware issues and was constantly learning new skills to improve my craft. However, after a few years, I felt like I had hit a ceiling in terms of growth and wanted to explore other areas within the technology industry.

During the early years of my career, my focus was on troubleshooting hardware-related issues and ensuring that the systems were running smoothly. As technology evolved, the role of hardware support engineers changed. The shift towards software-defined infrastructure meant that there was less reliance on hardware components, and the focus shifted towards software optimization.

This shift led me to pursue a career in software engineering. I started learning programming languages and focused on building software applications that could run on different systems. With time, I became more involved in system administration and worked on configuring and maintaining servers, databases, and other software applications. I was intrigued by the concept of DevOps, which was just starting to gain traction at that time.

As my knowledge and experience grew, I became more interested in the field of reliability engineering. Reliability engineering involves ensuring that systems are reliable, efficient, and scalable. It requires a deep understanding of how different components of a system interact with each other and how to optimize them for better performance.

I was intrigued by the challenge of ensuring the reliability of complex systems, which led me to transition into the role of a Site Reliability Engineer (SRE). As an SRE, I am responsible for ensuring the reliability of software systems and infrastructure. My role involves designing and implementing systems that are fault-tolerant, scalable, and efficient.

One of the most significant changes that I have witnessed is the shift towards cloud computing. This has enabled companies to deploy and manage applications and services much more easily and efficiently than before. With cloud computing, it is possible to easily scale up or down resources as needed, which has made it much easier to handle sudden spikes in traffic or demand.

Another significant change that I have witnessed is the shift towards automation. In the past, many tasks and processes had to be done manually, which was time-consuming and often prone to errors. Today, we have a wide range of automation tools and technologies that enable us to easily manage and automate many tasks and processes.

As an SRE, I have had to adapt to these changes and stay up-to-date with the latest technologies and trends. This has required a great deal of ongoing learning and training, but it has also been very rewarding. I have been able to work with a wide range of technologies and collaborate with other professionals from around the world.

In summary, my career path from a computer hardware support engineer to an SRE has been an exciting and challenging journey. It has required me to adapt to new technologies and learn new skills continually. I have enjoyed the challenges that have come with each new role and look forward to the opportunities that lie ahead.

Serverless: The Future of Cloud Computing

Wed, 15 Mar 2023 12:57:02 +0100

The concept of serverless computing has revolutionized the way developers build and deploy applications in the cloud. Serverless computing, also known as Function as a Service (FaaS), allows developers to focus on writing code without worrying about managing servers or infrastructure. In this blog post, we’ll explore what serverless computing is, how it works, its benefits and some of the Serverless services offered by AWS, the most popular Cloud provider.

What is Serverless Computing?

Serverless computing is a cloud computing model where the cloud provider manages the infrastructure, allowing developers to focus on writing code. With serverless computing, the cloud provider automatically provisions and manages the infrastructure required to run and scale your application. This means that you don’t have to worry about server management, capacity planning, or infrastructure scaling.

How Does Serverless Computing Work?

Serverless computing works by executing code in response to events. An event can be anything that triggers your code to run, such as an HTTP request, a database change, or a file upload. When an event occurs, the cloud provider runs your code in a container and then destroys the container once the code has finished executing. This means that you only pay for the time that your code runs, making serverless computing a cost-effective solution.

Benefits of Serverless Computing

One of the biggest benefits of serverless computing is scalability. With serverless computing, your application can scale automatically in response to changes in traffic or workload. This means that you don’t have to worry about managing the underlying infrastructure or scaling your servers manually.

Another benefit of serverless computing is cost savings. With serverless computing, you only pay for the compute time that your code actually uses. This means that you don’t have to pay for idle resources or overprovision your infrastructure to handle spikes in traffic.

Serverless computing also provides faster time to market for your applications. With serverless computing, you can focus on writing code instead of managing infrastructure, which allows you to release new features and updates more quickly.

AWS Serverless

AWS offers a range of serverless services, including:

Reflecting on 10 Years of DevOps

Tue, 03 Dec 2019 16:31:17 +0100

“It’s not my machines, it’s your code!” vs. “It’s not my code, it’s your machines!”

It has been 10 years since John Allspaw and Paul Hammond proposed Dev and Ops co-operation during their talk at the 2009 Velocity Conference. DevOps practise has progressed a long way since then. However, DevOps is just entering mainstream slowly now a days. DevOps practise came into existence as a way to solve never ending fights between Development team and Operations team to enable faster deployments to production. At this point, it might be a good idea to understand what exactly is DevOps? Is it a job role? Is it just about tools? Is it about some way of working or culture?

What is DevOps

Definition of DevOps means a lot of different things to different people because it covers a lot of ground. In a nutshell, it is co-operation between developers and operations team. One popular definition of DevOps is as below:

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.

People define DevOps such as “Developer - Operations collaboration” or “treating your Infrastructure as Code” or “using automation” or using a “Kanban approach” or using some “tool chains” or even “culture”. The best way to define DevOps is to consider it as an extension of Agile Development. It distills down to better collaboration of customers, product management, developers, and QA to fill in the gaps and rapidly iterate towards a better product. There are Three primary practise areas in the context of DevOps:

Infrastructure Automation

Create your servers, OS, Configurations and Application Deployments as code.

Continuous Delivery

Build, Test and Deploy your applications in a fast and automated way.

Site Reliability Engineering (SRE)

Responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of services.

Stop Hiring DevOps Engineers

One of the interesting talks in DevOpsDays Berlin by Stevan Cvetković was titled “Stop Hiring DevOps Engineers”. DevOps is not a role, automation or a tool. It is a way of working. This is exactly why it is so hard to implement it right. It is a set of principles that define how entire organization should be operating.

The author of this talk recommends to imbibe DevOps culture in the entire organization. Start from the top to bottom. Ensure 100% buy-in from the top management for DevOps transformation. Identify leaders to spearhead this transformation.

Ensure Agile is working perfectly. Agile is the strong foundation absolutely necessary for the successful implementation of DevOps transformation. Embrace experimentation and convert each failures into a learning opportunity. Make development teams care about builds and deployments. Dev and Ops teams working together can efficiently optimize delivery pipelines.

Build shared responsibilities: ensure development team understand the impact of code changes to the customers as well as the underlying infrastructure. Invest in automation tools for Continuous Delivery and Infrastructure as Code.

Make work visible and embrace transparency. Ensure Ops teams are aware of Product roadmap and major changes.

Measure everything: monitor all stages of build and deployment pipeline and create visible dashboards shared with all stakeholders.

Roll up your sleeves and encourage every engineers of development and operations teams to be DevOps Engineers.

DevOps vs SRE

SRE is the specific implementation of DevOps at Google, while Google likes to define DevOps as a “generalization of several core SRE principles to a wider range of organizations, management structures, and personnel”. SRE is a more formal implementation of DevOps practises with stringent controls. Google have lots of experience running several customer facing systems at a very large scale. Google have shared lots of details about SRE and how their SRE teams works to automate, run and maintain their web-scale systems.

Data Is Indeed The New Oil

Tue, 19 Nov 2019 15:52:45 +0100

Data is just like crude. It’s valuable, but if unrefined it cannot really be used. It has to be changed into gas, plastic, chemicals, etc to create a valuable entity that drives profitable activity; so must data be broken down, analyzed for it to have value.

Clive Humby

It has been more than a decade since Clive Humby coined the term “Data is the new oil”. We now have all the evidence to believe that this is so true. Just like oil, data is not much usable in its crude form. Data is the important input for Machine Learning Algorithms to train its systems. However, most of the times, raw data may not be directly usable for neural networks. Data needs to be cleansed and normalised. Data is the oil of digital era. Just like oil in the last century, giants that deal in data - Google, Facebook, Amazon, Apple and Microsoft are racking up billions and are seemingly unstoppable.

Worlds biggest Internet companies’ (FAANG) control of data gives them immense power. Today is the age of data explosion, and the means and facilities to analyse and make use of the wealth of this data is a gold mine for them. Amazon seems to be one step ahead in this game just like their first mover advantage in profiting from Cloud.

AWS Data Exchange

Amazon Web Service announced the release of AWS Data Exchange last week. This service does exactly the same thing as the name implies: Acting as an exchange of data products between providers and consumers of data. This service enables consumers to purchase data products available from multiple providers, load the data into S3 storage, and then analyze with various Data analytics and Machine learning services from AWS.

Target customers of this new AWS service are companies in Financial Services, Consumer & Retail, Healthcare & Life Sciences domains. Currently, the AWS Data Exchange product catalogue includes data from providers such as Reuters, Foursquare, TransUnion, Change Healthcare, Virtusa etc.

It is indeed clear that rich dataset on various topics is a very important raw material for todays conglomerates and behemoths!

Embarking on a Journey With Go

Thu, 14 Nov 2019 13:48:20 +0100

Today, I am embarking on a journey to learn Go!

Before explaining more about the journey, let me tell you a little bit of background. Recently, I have decided to become more organized in setting learning goals and achieveing them. I have experienced that gentle technology enabled reminders helps a lot to keep focus and avoid distractions. For example, the Activity Rings in Apple Watch. It was an eye-opener that how much it motivates to close those rings and achieve fitness goals every day without fail. I really liked the Activity Rings and searched for similar apps to set personal development goals. At the moment, I am trying out Streaks App, and hope it helps.

One of the goals I have set in Streaks is to learn new languages. Two languages in this case to be exact: One human language and one Programming Language. German is the human language and Go is the Progamming Language I have decided to learn.

Today marks the historical first day in my pursuit of learning Go!

Why Go?

I have heard a lot of good things about Go. Even this blog takes advantage of Go in its internal workings. This blog is created in a static site generator and deployed to GitHub Pages. The Static Site Generator in this case is Hugo. You have guessed it correct! Hugo is written in Go.

Go is a newer language and is very quickly rising in popularity.

Go is invented by geniuses in the Computer Science domain and is Open Source.

Go is designed to support concurrency and multicore CPU architecture.

Go is highly performant and is best suited for systems programming.

Above all, it is more human readble and easier to learn.

Wish me luck!

Temporary Table Could Not Be Re Created

Tue, 29 Oct 2019 08:51:53 +0100

Temporary tables with the same name could not be (re) created in a procedure – a case study

A complex SQL server procedure is under development. The Developer wants to reduce the complexity, he noted that if intermediate results are populated to a staging table, the logic would be much simpler.

No worries!! He created an intermediate table on the fly. Everything work perfect. The modified code looks like the following:

Some Code:

if object_id ( ‘temptab’) is not null
begin
drop table temptab;
end
create table temptab( n1 int, n2 int)

Do the processing.

A Proof of concept is presented. Perfect on demo!

Now a similar logic is to be applied for six different sets of data within the same procedure,code snippet for each set of data would be developed by a separate developer. The team decided to do a copy and paste of the code that is already in place.

Hmm !!! Copy and Paste !! Anyway the table temptab is dropped and re-created each time, should not be a problem. The modified code looks like the following:

/* For first data set */
– some code
if object_id ( ‘temptab’) is not null
begin
drop table temptab;
end
create table temptab( n1 int, n2 int);

some code in between…

/* For second data set */
if object_id (‘temptab’) is not null
begin
drop table temptab;
end
create table temptab( n1 int, n2 int) ;

So far so good..

Now the Villain ( none other than the DBA ) comes into scene, he does not like the idea of dropping and recreating a permanent table from within a procedure. He preaches of N number of reasons against the practice.

What to do now ? Obvious choice – use a temporary table instead. It should be simple – code is modified as follows:

/* For first data set */
– some code
if object_id ( ‘tempdb..#temptab’) is not null
begin
drop table #temptab;
end
create table #temptab( n1 int, n2 int);

some code in between…

/* For second data set */
if object_id (‘tempdb..#temptab’) is not null
begin
drop table #temptab;
end
create table #temptab( n1 int, n2 int) ;

Oh No! The procedure is not getting created, It is failing with an error message

Msg 2714, Level 16, State 1, Line 10 There is already an object named ‘#temptab’ in the database.

You read it correctly, the message is -

There is already an object named ‘#temptab’ in the database.

Code is re-examined n number of times, not any issues were found. Logically it should drop the temporary table and re-create it, Right ? But reality is far from that ! Perplexed ?? But it was working perfectly with permanent table ! What is the problem with temporary tables?

Let us see what Microsoft states about it:

“If more than one temporary table is created inside a single stored procedure or batch, they must have different names.”

Does it mean that we cannot re-create a temporary table from within a procedure with the same name ? Let us check one more link –

SQL Server Tips & Tricks

Crystal clear – This is a ‘feature’ by design.

If you come across a similar issue don’t waste your valuable time to resolve. Instead look for workarounds.

Thank you for visiting this post. Highly appreciate your feedback and comments. Happy reading.

About the Author

Anoo S Pillai

Senior SQL Server DBA

Specializing in high availibility, disaster recovery and performance tuning

Blogging With Hugo

Mon, 09 Sep 2019 16:41:04 +0200

It’s been a while since this blog was updated. Today, I’ve decided to bring a new life to my blog with a new backend and a new theme. In the beginning, I had been using Wordpress for blogging but felt like it was overkill for such a simple blog. I was searching for a simpler approach for publishing my blog and thats when I stumbled upon Jekyll. So I decided to try it out. However the experience was not ideal for me.

Then I learned about Hugo and decided to give it a try. My experience with Hugo has been very positive. In comparison to Jekyll and Wordpress, setting up Hugo was a breeze. I was able to install Hugo, set it up and deploy the site to GitHub Pages on my custom domain - all under 30 minutes!

About

Mon, 01 Jan 0001 00:00:00 +0000

Thank you for visiting Techtalks.

My name is Vibin Andrews Kurusingal. I am an IT Professional, Private Pilot and a Hobby Photographer based in Germany.

Currently, my professional focus is at the forefront of LLM Ops. I bridge the gap between traditional Site Reliability Engineering (SRE) and the unique demands of Large Language Models. I specialize in the operationalization of Generative AI (GenAI)—building the robust infrastructure, deployment pipelines, and observability frameworks necessary to move AI from experimental demos to stable, scalable production environments. My goal is to apply the principles of high availability and automation to the evolving world of intelligent systems.

Aviation & Photography

My passion for aviation has transitioned from the ground to the cockpit. I am currently pursuing my pilot’s license, gaining hands-on experience across a diverse range of aircraft, including gliders, motorgliders, and light motor planes. I find that the technical precision required to master the distinct flight characteristics and operating disciplines of these different aircraft perfectly complements the analytical mindset I bring to AI engineering.

When I’m not in the air or at my desk, I spend my time as a Hobby Photographer, capturing the world through my lens—with a particular focus on aviation and the unique perspectives found across Germany.