Forem: Amr El-Bakry

Consistency for Agile Teams

Amr El-Bakry — Wed, 15 Apr 2020 12:51:10 +0000

As an agile team, we are working tirelessly to deliver working software. Periodically, we pause and reflect on what we delivered, what we didn't, and what could be improved; whether it's the process itself, the organization of the team, or the tools. We improve, restart, and repeat.

It gets tempting to pursue one improvement after another, and naturally, there's always something to improve. However, in one of our meetings, our team decided to shift focus to something else: consistency. Before we improve, we need to be consistent.

Consistency, how?

We have delivered the sprint goal. All is well. Now, instead of looking for improvements that will supposedly help us deliver more, we will maintain the same pace and try to do it for another two sprints. If we are able to do that, then we are consistent. And now, we can introduce gradual improvements and be consistent with them.

If not, then there's something that needs to be fixed. Let's revisit our process and progress and see where it went wrong. After finding and fixing the issue, we can try to be consistent again.

Sounds easy enough! But it is not. It takes good, clear communication, discipline, and commitment from each team member.

Consistency and Change

Consistency is not about sacrificing change. It is rather about striking a balance between the two. Before adding new functionality or behavior, we should be consistent, and thus confident that it won't break already existing ones.

Change is inevitable, and we'd rather have a solid foundation that allows us to respond smoothly to that change; this solidity comes through being consistent.

this post was also published on our (RealxData) blog and medium

TIL: Using Different Database Connection with ActiveRecord Transactions

Amr El-Bakry — Thu, 14 Feb 2019 23:40:53 +0000

I came upon an interesting problem a few days ago at work. I had some code inside an active record transaction that updated some record in the db, called an external service, and then updated another record based on the response from that external service. It was something like this:

def call
  ActiveRecord::Base.transaction do
    record1.update!(some_data)
    external_service_response = Communicator.call!(record1, save_error: true) # raises exception if response is not a success
    record2.update!(external_service_response)
  end
end

The communicator class uses record1 data to build a request and call an external service. It also handles authentication and response parsing; if the response is a success, it parses and returns it. otherwise, it updates a record in the db with the error response if the save_error flag is set to true, and finally raises an exception, causing the active record transaction to roll back everything.

The Problem

the issue was that the error response was not saved to the db. Do you see why?! Because it's inside the transaction; so when the communicator class raises an exception, the transaction rolls back everything, including the operation to save the error message to the database. well, duh.

The Solution

the most obvious solution and the one you should go for in most cases is to move the communicator call outside the transaction, and the save error operation won't be rolled back. However, I couldn't do that so I had to do more thinking and googling...

I came across another neat solution and definitely learned something new. It uses the fact that an active record transaction "acts on a single database connection"; which basically means that if we use a different connection -from the one the transaction is using- to update a record, the transaction won't cover the update operation, and it won't be rolled back in case of an exception.

So, to solve my problem, I need to make a new thread (since each thread will use a different database connection), obtain a connection, and update the record with the error response.

ActiveRecord::Base.connection_pool

and to achieve all that, and to manage the database connections properly and make sure it's thread safe, we have ActiveRecord::Base.connection_pool

From the docs:

A connection pool synchronizes thread access to a limited number of database connections. The basic idea is that each thread checks out a database connection from the pool, uses that connection, and checks the connection back in. ConnectionPool is completely thread-safe, and will ensure that a connection cannot be used by two threads at the same time, as long as ConnectionPool's contract is correctly followed.

and so the final solution becomes:

# communicator class
# 
# in case of error response
def save_error_response(record)
  Thread.new do
    ActiveRecord::Base.connection_pool.with_connection do
      record.update(external_service_error_response)
    end
  end.join
end

the with_connection method will check out a connection, yield to the block (update the record), and check in the connection again to the pool after finishing. We also need to join the thread to make sure the main thread will wait for it to finish before exiting.

That's it! Now, the error response will be saved to the database and won't be rolled back in case of an exception as it's in a different thread and different connection from the transaction.

I hope my explanation of the problem and the solution was clear.

this post was also published on medium.

The Importance of Selective Learning

Amr El-Bakry — Fri, 25 Jan 2019 20:11:34 +0000

We are very lucky to live in a time in which new technologies emerge every day to help us build all sort of stuff and make our lives easier. There's always this awesome tool or language that you want to learn and use because it introduces a new way of thinking or a different paradigm.

And with today's access to information and learning resources, and if you know how to do your google search, you will find a plethora of resources to help you learn that tool or language and a plethora of many more things to learn. It can get overwhelming.

Learning is a skill in itself and those of us who are able to learn fast are blessed, but it's also important to remember that it's not a race. Learn at your own pace; as long as you're learning, you should take all the time you need. But before you embark on this journey of learning, you should take a moment to consider if you really need to invest all this time to learn this and/or that tool. Because you can learn anything but you can't learn everything; that's why you should be especially selective about what you learn.

There will always be temptations to start using this new language because of how awesome and revolutionary it is or how it will replace this other language, however, this doesn't mean that you should drop everything and start investing time to learn it. Take a step back and thoroughly think if you actually need to learn it.

Being selective about what you learn is how you distinguish yourself from others. It is essentially about what you know well not how much you know.

and remember to never stop learning!

this post was also published on medium

Runtime Introspection in Ruby

Amr El-Bakry — Thu, 02 Aug 2018 08:57:55 +0000

Ruby offers a variety of methods that allows you to ask an object about its capabilities (which messages/methods does it respond to?), its variables and constants, and its backstory (the object's class and ancestors).

Methods Introspection

Let's start by asking an object about its non-private methods:

str = 'a string'
str.methods

# => [:include?, :%, :*, :+, :unicode_normalize, :to_c, :unicode_normalize!, :unicode_normalized?, :count, ...]

methods returns an array of symbols representing the names of the public and protected methods for the receiver string object str.

We could also ask the object about:

private_methods
public_methods
protected_methods
singleton_methods

by default, Ruby will look up and list all the methods in the object's class and its ancestor classes and modules. If you want to list methods in the object's class only, you could pass the argument false or nil to any of these methods.

str = 'a string'
str.public_methods(false)

# public methods defined in String only
# => [:include?, :%, :*, :+, :unicode_normalize, :to_c, :unicode_normalize!, :unicode_normalized?, :count, ...]

Sometimes, you'll only need to know if an object knows about a specific method, and that's when we use the aptly-named respond_to?:

str = 'a string'
str.respond_to?(:include?)
# => true
str.respond_to?(:first)
# => false

Variables and Constants Introspection

In the same sense, we can query a class about instance_variables, class_variables, and constants.

class Cat
  @@cats_count = 2

  CATS = ['Luna', 'Milo']

  attr_accessor :name, :age

  def initialize(name)
    @name = name
  end
end

cat = Cat.new('Max')
cat.age = 2

cat.instance_variables
# => [:@name, :@age]

cat.class.class_variables
# => [:@@cats_count]

cat.class.constants
# => [:CATS]

Also, there are top-level methods to list local_variables and global_variables.

# irb session
>> local_variables
# => [:_]

This underscore local variable is actually a very interesting one; it always holds the last evaluated expression:

Cat.new('Milo')
# => #<Cat:0x00000002415440 @name="Milo">
cat = _
# => #<Cat:0x00000002415440 @name="Milo">

The Object's Backstory

Finally, let's ask the object about its class, superclass, and ancestors

cats = ['luna', 'milo']
cats.class
# => Array

cats.class.superclass
# => Object

cats.class.ancestors
# => [Array, Enumerable, Object, Kernel, BasicObject]

ancestors returns a list which includes its receiver (Array) and modules included in Array (Enumerable, Kernel), Array's superclass (Object), and lastly the superclass of Object which is (BasicObject).

But that's not it. There are also more convenient ways to ask about the object's class...

is_a?
kind_of?
instance_of?

this trio of predicate methods could also help us with that query:

cats = ['luna', 'milo']
cats.is_a?(Array)
# => true

One important difference to note here is that instance_of? will only return true if the receiver object is a direct instance of the class and not of a subclass:

class A; end
class B < A; end

b = B.new
# => #<B:0x00000001fac638>
b.kind_of?(A)
# true
b.instance_of?(A)
# false

This was just a glimpse of ruby's introspection capabilities, but there are always very interesting things you can learn about your objects!

This article can also be found on Medium.

Hi, I'm Amr El-Bakry

Amr El-Bakry — Thu, 13 Jul 2017 10:54:05 +0000

I have been coding for 3 years.

You can find me on Twitter as @amrrbakry

I live in Cairo.

I work for Eventtus.

I mostly program in these languages: Ruby, Rust, Javascript.

I am currently learning more about Rust.

Nice to meet you.