TILs - Fueling Curiosity, One Insight at a Time

At Codemancers, we believe every day is an opportunity to grow. This section is where our team shares bite-sized discoveries, technical breakthroughs and fascinating nuggets of wisdom we've stumbled upon in our work.

Published: Feb 20, 2025
Author: Nitturu Baba
System Analyst

Real-time AI response streaming improves user experience by reducing wait times and making interactions feel more dynamic. Instead of waiting for the entire response to be generated before displaying it, streaming allows data to be processed and presented incrementally.

Example of AI response streaming using Nest Js backend and Next JS front end.

Setting Up the NestJS Backend for Streaming AI Responses

Controller

TypeScript

import { Controller, Post, Body, Res } from '@nestjs/common';
import { openai } from '@ai-sdk/openai';
import { streamText } from 'ai';
import { Response } from 'express';

@Controller('orchestrator')
export class OrchestratorController {

 @Post('chat')
 async chat(@Body() payload: any, @Res() res: Response) {
  const { messages } = payload;

  const result = streamText({
   model: openai('gpt-4o'),
   messages,
  });
   
  result.pipeDataStreamToResponse(res); // Streams the AI response directly to the client
 }
}

How It Works
• The @Post('chat') endpoint listens for chat requests.
• The streamText function sends user messages to OpenAI and receives a streamed response.
• pipeDataStreamToResponse(res) directly streams the AI-generated content to the client as it arrives.
Building the Next.js Frontend for AI Response Streaming

chat/page.tsx

JavaScript

'use client';

import { useChat } from '@ai-sdk/react';

export default function Home() {
 const { messages, input, handleInputChange, handleSubmit } = useChat({
  api: 'https://localhost:3000/api/orchestrator/chat',  // make the post request to the NestJS backend
 });

 return (
  <div>
   {messages.map((message) => (
    <div key={message.id}>
     {message.role === 'user' ? 'User: ' : 'AI: '}
     {message.content}
    </div>
   ))}

   <form onSubmit={handleSubmit}>
    <input
     name="prompt"
     value={input}
     onChange={handleInputChange}
     className="text-black"
    />
    <button type="submit">Submit</button>
   </form>
  </div>
 );
}

How It Works
• The useChat hook from AI-SDK manages state and streaming logic automatically.
• It sends user messages to the backend and updates the UI in real time as responses arrive.
• The messages array dynamically updates, displaying each chunk of AI-generated text as it's received.
#C08DPTN3JAW #streaming #next js #nest js

Published: Feb 20, 2025
Author: Puneeth kumar
System Analyst

Collection caching is a way to speed up rendering multiple items on a page by storing their HTML in cache.
How it works:
1. When we use <%= render partial: 'products/product', collection: @products, cached: true %>, Rails checks if each product's HTML is already stored in the cache.
2. If a product’s HTML is found in the cache, Rails loads it quickly instead of rendering it again.
3. If a product’s HTML is not in the cache, Rails will render it, store it in the cache, and use it next time.
4. The big advantage: Rails fetches all cached products at once (instead of one by one), making it much faster.
#CU6U0R822 #caching #collection_caching

Published: Feb 19, 2025
Author: Nived Hari
System Analyst

When testing with Capybara, you might need to scroll an element into view before interacting with it. Instead of using JavaScript like:

JavaScript

page.execute_script("arguments[0].scrollIntoView(true)", button)

You can use Capybara's built-in method:

Code

scroll_to(button)  # Scrolls to the element

This is available in
Capybara 3.26+
and is the preferred way to ensure visibility before clicking or interacting with an element.

#capybara #CU6U0R822 #C041BBLJ57G

Published: Feb 19, 2025
Author: Nived Hari
System Analyst

In JavaScript, you can use localeCompare with { sensitivity: "base" } to compare strings without considering case or accents.
Example:

JavaScript

"Test".localeCompare("test", undefined, { sensitivity: "base" }) === 0; // ✅ True
"café".localeCompare("cafe", undefined, { sensitivity: "base" }) === 0; // ✅ True
"Hello".localeCompare("HELLO", undefined, { sensitivity: "base" }) === 0; // ✅ True

• Case-insensitive
• Accent-insensitive
No need for toLowerCase() hacks anymore! 🎉

second argument is locale . by giving it as "Undefined" it uses default locale of the runtime environment. We can specify as "en", "id" etc. It is used in sorting scenarios ig.

Sensitivity is the behaviour of the comparison

Code

"base" → Ignores case & accents ("café" == "cafe", "Hello" == "hello")

"accent" → Considers accents but ignores case ("café" != "cafe", "Hello" == "hello")

"case" → Considers case but ignores accents ("café" == "cafe", "Hello" != "hello")

"variant" → Considers both case & accents ("café" != "cafe", "Hello" != "he

#stimulus #JavaScript #StringComparison

Published: Feb 19, 2025
Author: Nived Hari
System Analyst

By default, Capybara only finds visible and interactable elements. If a button is disabled or outside the viewport, Capybara may fail to locate it.
To fix this, use:

Code

expect(page).to have_button("Add Discrepancy", disabled: true, visible: :all)

• disabled: true ensures the button is actually disabled
• visible: :all allows Capybara to find buttons that are hidden, off-screen, or disabled
This is useful when testing UI behaviors where buttons are conditionally enabled/disabled or require scrolling to be visible.

#CU6U0R822 #capybara #C041BBLJ57G #specs

Published: Feb 5, 2025
Author: Puneeth kumar
System Analyst

local_assigns :
When using partial views in Rails (like _partial.html.erb), we might pass local variables to customize the rendering. However, if we try to use a local variable that wasn't passed, Rails will raise an error.
To avoid this, local_assigns is a special hash that helps check if a local variable was provided when rendering the partial. Instead of directly using <%= show_projects %>, which could cause an error if missing, we can safely check local_assigns[:show_projects] first.

Ruby

<% if local_assigns[:show_projects] %> 
  
    <%= (render @user.projects) || (render 'shared/empty_state', message: "No projects found!") %>
   
<% end %>

Here, the partial checks if show_projects was passed before using it. If show_projects was provided, it renders the user's projects or a message if no projects are found. If show_projects wasn't passed, nothing happens, preventing errors.

Published: Jan 27, 2025
Author: Mohammad hussain
System Analyst

The Rails 8.0 release introduces several new features, and among them, params#expect stands out.

In our daily work with Rails, we often rely on params#require for assignments and queries. However, params#require is more explicit than permit. Here’s an example to illustrate:

Ruby

params = ActionController::Parameters.new(posts: [{id: 1}])

If you expect the posts parameter to contain a list of IDs, such as [{id: 1}, {id: 2}], you can define your expectations like this:

Code

params.expect(posts: [[:id]])

The output will be:

Code

[
  #<ActionController::Parameters {"id"=>1} permitted: true>,
  #<ActionController::Parameters {"id"=>2} permitted: true>
]

Now, consider a different scenario where you expect the posts parameter to have only a single hash with an ID, like this:

Code

params = ActionController::Parameters.new(posts: {id: 1})

If you use:

Code

params.expect(posts: [[:id]])

It will raise the following error:

ActionController::ExpectedParameterMissing: param is missing or the value is empty or invalid: posts
In contrast, using the older params#permit:

Code

params.permit(posts: [:id])

Will not enforce your expectation of the nested parameter structure and will accept it without validation.

Published: Jan 21, 2025
Author: Giritharan
System Analyst

Rails Inflections:
What is it? Inflections in Rails, powered by the ActiveSupport::Inflector module, allow customization of how words are pluralized, singularized, or treated as uncountable.
Why use it? Sometimes Rails' default pluralization rules don't fit your app's needs (e.g., irregular words like foot → feet, uncountable words like milk).

Examples

• Default Behavior:

Code

"person".pluralize  # => "people"
"person".singularize # => "person"

• Irregular Inflections:

Code

ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.irregular "foot", "feet"
end

// "foot".pluralize  # => "feet"

• Uncountable Words:

Code

ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.uncountable "milk"
end

// "milk".pluralize  # => "milk"

• Acronym Inflections:

Code

ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.acronym "HTML5"
end

// "html5".camelize  # => "HTML5"

Potential Issues:
• Default Behavior May Be Inaccurate: Without customizing, words like "tooth" become "tooths" or "milk" becomes "milks."
• Localization: Inflections are locale-specific, so customizations for one locale won't apply to others.
Best Practice: Always define rules for edge cases (irregular, uncountable, acronyms) in your config/initializers/inflections.rb ans restart the server after changes

#rails-inflections #active-support #CU6U0R822

Published: Jan 17, 2025
Author: Ashwani Kumar Jha
Senior System Analyst

EXPLAIN ANALYZE Command in PostgreSQL

1. EXPLAIN: shows the query execution plan that PostgreSQL's query planner generates for the specified query. It tells us how PostgreSQL plans to execute the query, including:
◦ What type of scan it will use (sequential scan, index scan)
◦ The estimated cost
◦ The estimated number of rows
2. ANALYZE: actually executes the query and shows the real results, including:
◦ Actual time taken
◦ Actual number of rows processed
eg:

Code

EXPLAIN ANALYZE select * from public.card
where card_number='120000024223'

When we will run this command, we'll see output that looks something like this:

Code

Seq Scan on public.card  (cost=0.00..11.75 rows=1 width=180) (actual time=0.016..0.018 rows=1 loops=1)
  Filter: ((card_number)::text = '120000024223'::text)
Rows Removed by Filter: 100
Planning Time: 0.152 ms
Execution Time: 0.034 ms

Here in this output:
• Seq Scan on public.card:
◦ This indicates PostgreSQL is doing a sequential scan (reading the entire table)
◦ cost=0.00..11.75: unit-less value that represents PostgreSQL's estimate of how expensive the query will be
◦ rows=1: PostgreSQL estimates it will find 1 row
◦ width=180: Estimated average width of each row in bytes
◦ actual time=0.016..0.018: Actual time taken (in ms)
◦ rows=1: Actually found 1 row
◦ loops=1: The operation was performed once
• Filter: ((card_number)::text = '120000024223'::text):
◦ Shows the WHERE clause condition being applied
• Rows Removed by Filter: 100:
◦ 100 rows were checked but didn't match the condition
◦ This means the table had 101 total rows (100 filtered + 1 matching)
• Planning Time: 0.152 ms:
◦ Time taken to generate the query execution plan
• Execution Time: 0.034 ms:
◦ Actual time taken to execute the query
This can be used for:
• Debugging performance issues
• Finding bottlenecks in query performance
#PostgreSQL #query

Published: Jan 13, 2025
Author: Syed Sibtain
System Analyst

Shared Context in RSpec

Shared Context: A shared context in RSpec is a way to define common setup code that can be reused across multiple test examples or groups. Instead of duplicating setup code, we define it once in a shared context and include it wherever needed. It helps keep our tests DRY.

Ruby

RSpec.shared_context "user and post setup", shared_context: :metadata do
  let(:user) { User.create(name: "Alice") }
  let(:post) { Post.create(title: "First Post", user: user) }
end

RSpec.describe "Using shared context in tests" do
  include_context "user and post setup"

  it "has a user with a name" do
    expect(user.name).to eq("Alice")
  end

  it "has a post with a title" do
    expect(post.title).to eq("First Post")
  end
end

In the example, the shared context user and post setup defines let variables for a user and a post.
By including the shared context with include_context, we gain access to those let variables in the test examples.

#rspec #rubyonrails

Showing page 10 of 83

Your competitors are already using AI.
The question is how fast you want to unlock the value.

Don't know where to start?

AI is everywhere but it's unclear which investments will actually move your metrics and which are expensive experiments.

Your data isn't ready

Most AI projects fail at the data layer. Pipelines, quality, access all need work before LLMs can deliver value.

Internal teams are stretched

Your engineers are shipping product. They don't have capacity to also become AI specialists with production-grade experience.

Legacy systems block everything

Aging, undocumented codebases make AI integration slow, risky, and expensive. They need to move first.

Don't worry. We've got you covered.

Start with the audit.

Book a free discovery call →

TILs - Fueling Curiosity, One Insight at a Time

TypeScript

JavaScript

JavaScript

Code

JavaScript

Code

Code

Ruby

Ruby

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code

Ruby

Your competitors are already using AI.The question is how fast you want to unlock the value.

Don't know where to start?

Your data isn't ready

Internal teams are stretched

Legacy systems block everything

Don't worry. We've got you covered.

Your competitors are already using AI.
The question is how fast you want to unlock the value.