Today’s AOC problem was a bit of a trap! The first part was so easy, that I got carried away and failed to notice the complexity till my solution slapped me on the face with an OOM!! It was so inefficient that 8 GB of heap space was not enough.

The problem statement

Here are the fresh ingredient ID ranges

3-5
10-14
16-20
12-18

The ingredient IDs that these ranges consider to be fresh are 3, 4, 5, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, and 20. So, in this example, the fresh ingredient ID ranges consider a total of 14 ingredient IDs to be fresh.

It is that time of the year when everyone eagerly awaits to solve the AOC problem everyday. Today’s problem was pretty easy to understand as a human, but it is a bit hard to come up with an algorithm to solve it efficiently.

Given an input 234234234234278 we need to come up with the largest 12 digit number, without changing the order of the digits 434234234278 in this case. In other words, we need to derive a subsequence from the input.

I’ve observed a lot of folks (including me) struggle in our initial attempts to get copilot write the code we want. The common entry barrier in such cases, is “prompting”.

With all the attention prompt engineering is getting in recent times, developers tend to think,

“How do I come up with the most effective prompt, that’d make copilot write the code that I have in mind?”

As it turns out, arriving at the right prompt, in itself, is an iterative process. So, you’re never going to get the prompt right in first place always going to take a few attempts before copilot spits out the code you expected.

I spent this weekend by writing an Elixir script to solve the Linear Regression problem. And then when I went on to implement Gradient descent to train the model, I hit a road block.

I came up with this code, which looked perfect to me, just that it didn’t work. It didn’t do what I expected this to do.

  def train_from(filename) do
    raw_dataset = read_dataset(filename)
    x = raw_dataset |> Enum.map(fn d -> elem(Integer.parse(Enum.at(d, 0)),0) end)
    y = raw_dataset |> Enum.map(fn d -> elem(Float.parse(Enum.at(d, 1)),0) end)
    training_dataset = %{x: x, y: y}
    w = 100
    b = 100

    for n <- 1..5 do
      IO.inspect("Iteration #{n}: #{w}, #{b}")
      [w, b] = gradient_descent_step(x, y, w, b)
      IO.inspect("End of Iteration #{n}: #{w}, #{b}")
    end

    IO.inspect("End values for w: #{w}, b: #{b}");
  end

It spit out this output.

I’ve been trying my hand at creating something with Copilot for the last two weeks. The one question that I set out to find an answer is,

“Can copilot really replace pair programming?”

I’ve spent a good amount time of my career crafting code and 80% of the time the code was co-created with my pair. So, there was an initial hesitation to try this out. But one fine day, I crossed the chasm and got started on my experiments with copilot.

What is Gradient Descent?

Gradient descent is an optimisation algorithm used in machine learning to deduce the optimal weights / parameters that incurs minimum cost for the model being trained.

A machine learning model needs to be trained on a dataset before it can start predicting. We can call training as done, if we have figured out the optimal values for its parameters. We can say the parameter values are optimal when the cost (difference between prediction and actual) is minimum. Gradient descent helps us find the optimal parameters for a model, given the training data and cost function.

You cannot improve anything that you cannot measure.

For teams on a Agile transformation journey, they may want to know at how mature they are. While I’m not a fan of ranking teams based on their maturity index (or similar), I think, within the team such assessments can be good starting points to identify what they have to focus on. In such cases, I’ve found James Shore’s agile maturity assessment to be a useful tool.

For any team that wants to adopt XP, it is important to make sense of the values, principles and practices and how they are connected to each other. Though, this understanding will solidify itself over time, it can be challenging to the team to sustain till then. And many teams may not have the luxury of allowing themselves the required time. Here, I attempt to put my understanding from practising XP over my years in Thoughtworks into words, hoping it’d help someone who is looking for this.

Started working on a rails app that needs to communicate with a SOAP based web service in the backend. We are using savon for talking to the web service. Every service call took a long time to process and we wanted to measure how much time is spent in the service calls. Inspired by rails_instrument, a middleware to show instrumentation information in http headers, I thought of writing a similar one for the SOAP calls that we make. SavonInstrument is born, and this is how it looks, for the sample application.

Came across a very weird issue while working with actionmailer last week. Debugging the issue gave a good understanding of how the mail gem (which actually constructs the message, body and its headers) works. The problem statement is to send multiple emails on some particular event. I went ahead and implemented this problematic piece of code

class MyMailer < ActionMailer::Base
  def send_multiple_mails(n)
    n.times do |i|
      mail(:to => 'receiver@gmail.com', :from => 'sender@gmail.com', :subject => "Mail no #{i}").deliver!
    end
  end
end

If you are still wondering what is the problem with this code, go ahead and try to send a mail to yourself using the above mailer for any value of n > 1. The basic rails code for the problem statement can be found here. You can notice that the first mail is sent successfully. And the subsequent emails do not contain the full text. It stops abruptly while constructing a html link. Weird. The logs told me that the headers of all the mails are the same, but still they are all delivered differently.