DEV Community: Chirag Jain

Opening office hours for mock interviews

Chirag Jain — Wed, 29 Apr 2020 15:47:12 +0000

I'm opening office hours to help folks prepare for interviews.

I'd conduct a mock interview.
I'll share actionable feedback with relevant resources.

You can book a slot here: https://calendly.com/chirag-jain/mock-inteview

On Abstraction – Zach Tellman - ClojuTre 2017

Chirag Jain — Sun, 24 Mar 2019 22:55:43 +0000

Zach Tellman is the author of the book "Elements of Clojure". In this talk titled "On Abstraction" he tries to define what is an abstraction and how do we can build better systems with a better understanding of what goes into making an abstraction.

The goal of the book was the best second book you read about Clojure, when you know what you can do with the language but you don't know what parts of the language to use to solve a particular problem.

The first chapter was about names: "Naming and Necessity". Even though it is well known that naming is a hard problem, CS doesn't have enough literature tackling the problem. "The analytics school of psychology" has explored the topic in excruciating detail.

The second chapter was about abstraction but there wasn't any literature directly targeting it and no other paradigm deals with this topic in depth.

Abstraction

The word abstraction is used to refer to 2 very distinct concepts, demonstrated by the following 2 ideas:

Church Numerals

Alonzo Church's lambda calculus introduced these. The numbers are represented as functions, the number 3 is a function which takes a function and applies it 3 times to a value.
Cons Cells

Typically used to create linked lists, with the base case of Nil representing an empty collection.

The Church Numeral weren't used in Computer Science because representing numbers in computationally intensive, they have been widely used in mathematics (which is timeless). Cons Cells are widely used in CS, because following a link is fast, but the landscape has changed rapidly the computer processing has increased more rapidly than the decrease in memory latency.

The most common formal definition of abstraction in CS literature comes from the paper: "Proof of Correctness of Data Representation" by Tony Hoare, who also brought us "Communicating Sequential Processes".

The paper introduces 2 major concepts:

Abstractions model the internal model onto the external semantics.

Invariant constrain the internal model.

Abstraction is the mapping of the internal implementation to the external interface. The invariant allows different implementations without being correct with respect to each other, they only have to satisfy the invariant. It however doesn't talk about the environment the object operates in.

To define an abstraction we need 3 parts:

Model

The implementation
Interface

The means to interact with the Model
Environment

Everything else

Model

The model is initially empty, all the data comes from the environment hence in a way the model reflects the environment. This is close to what Physics does to create models for real world concepts. We can't do this in Software as Physics uses deductive reasoning to create a model based on observation and keep tweaking it until the predictions are correct, to model this in software would require a very rick model.

50-60 years before physicists were actively involved in computer programming. In 1959 the first attempt at AI was made in a project called "General Problem Solver (GPS)" using means-end analysis.

Most of software instead relies on inductive reasoning which is based on analogy, this allows us to skip a lot of details making the models a lot simpler. Example: A tick — It latches onto something generating heat or secreting butyric acid above a certain threshold. We cannot create a perfect model for this but we don't need to. The model just needs to be accurate enough.

The model can only satisfice.

The book "The science of the artificial" by Herbert Simon (principal investigator for the GPS) coined the term satisfice for "pragmatically crappy solution".

It's easy to make deductive model, but hard to make a useful one. We can reduce something in terms of arithmetic for a deductive model but it it doesn't mean that the predictions would be right.

Models assume everything that they omit is either invariant or irrelevant. When assumptions leak out we have to use conventions. This doesn't make the assumption always valid, it makes it less likely to be invalid.

The interface

Interfaces represent the intersection of many models or one model over time.

Consequences of our Model

To abstract is to ignore.

To think is to forget a difference, to generalise, to abstract. In the overly refute world of Funes there were nothing but details, almost contiguous details.

We can't take into account all the details of the world in our programs, we have to make assumptions to reason about things efficiently.

An abstraction is useful only if the assumptions are sound given the context it's being used in.

That means the usefulness of the software is a function of the context it's being used in.

To know an abstraction's assumptions, we must know its model. Possession does not imply understanding.

If the model assumes too much, we can:

Make the model larger
Replace our model
Narrow our intended usecase

The following generations, who were not so fond of the study of cartography as their forebears had been, saw that the vast map was useless.

If an abstraction doesn't solve the user's problem, they can:

Discard the abstraction
Wrap the abstraction
Create Conventions

If an abstraction can't be discarded it becomes coercive. What it doesn't see might disappear.

Software would be easy, it it weren't for the changing environments.

The environment consists of 3 things:

The entire world
Users
Other software components

Systems of abstractions

There are 2 approaches:

Principled

Make everything predictably structured, so that the side-effects of changes can be predicted accurately.
Adaptable

Make the parts sparsely connected such that when we make a change we only have to reason locally about the system.

There are 2 kinds of cultures:

Self-conscious

There's an person called the architect, who is an expert in design and construction of buildings.
Unself-conscious

Everyone builds their own home and there not many other structures that they create.

Principled systems have hierarchies. There's a place for everything and everything is in it's place.

Adaptable systems are graph-like, they don't have a central organizing principle, we are able to make local changes to them.

If abstraction is an island our code becomes Galapagos. Variation is only useful when it mirrors the problem being solved.

Principled code is brittle and predictable. Adaptive code is flexible and unpredictable. There's no in between. What we can do is layer them.

Adaptable components in a principled framework. The degrees of freedom become vestigial and disappear. There's nothing to adapt to if the environment doesn't change.

Principled components in an adaptive framework are called complex adaptive systems. If the principled system is too small then we have to write a lot of glue code. If it's too large then the replacement cost becomes extremely high.

Assumptions that fail together, belong together.

Principled components are smaller faster and can be understood incrementally.

We tend to put our bias towards principled component too often due to our optimistic assumption about the environment due to lack of complete understanding.

Balance is the key here things like logging libraries should be principle components, everyone doesn't need to roll their own. While custom requirements should form the adaptive surrounding.

Original link to the talk

This is my 4th post in this series do check out the previous ones :)

Get a wiff of this - RailsConf 2016 - Sandi Metz

Chirag Jain — Sat, 09 Mar 2019 01:19:30 +0000

This is my 3rd post in my talk notes series.
Sandi Metz is a well known name. She has helped many teams refactor their systems from software rot. These are my notes on her RailsConf Talk about Code Smells.

Code Smells

"Code smells" is a term coined by Kent Beck for regularly observed patterns in code.

Martin Fowler wrote the "Refactoring" book on how to avoid duplication by encapsulating these patterns.

Code smells are grouped based on similar traits as follows:

Bloaters

Long methods
Large classes
Data clumps
Long parameter lists
Primitive obsession

Tool Abusers

Switch Statements
Refused Bequest : A sub class overrides a base class method and throws an exception to denote that it doesn't implement that behavior.
Alternative classes with different interfaces
Temporary fields: Can be a method instead

Change Preventers

Divergent Change: A change requires modifications at different branches of the same hierarchy.
Shotgun Surgery
Parallel inheritance hierarchies

It's fine sometimes that theirs friction to change. It depends on context.

Dispensable

Lazy classes: classes that don't do enough
Speculative Generality: Making abstractions for anticipated future usecases
Data Class: Classes with coupled data and behavior
Duplicated Code

Couplers

Feature Envy: Sending more messages to other objects than yourself i.e. coupling
Inappropriate Intimacy: Reaching into other object's private methods
Message Chains: Send a message, receive an object, send a message to received object and it goes on. If the type of object changes in between then it's more concerning.
Middle Man: An object with the sole purpose of routing messages to other objects.

Refactoring

Refactorings have name and they come with very specific concrete recipes.

Every code smell wraps to the curated refactoring recipe. This is a solved problem.

Smells to Refactorings Cheatsheet - Industrial Logic

Example

class Sale < Persistence
end

class Expense < Persistence
end

class Foo
  def sales_total(params)
    Sale.where(date:(Date.parse(params[:starting]))..(Date.parse(params[:ending]))).sum('cost')
  end
end

class Bar
  def weekly_sales_total(params)
    start_date = (Date.parse(params[:starting]))
    end_date = start_date + 6
    Sale.where(date:start_date..end_date).sum("cost")
  end
end

class Baz
  def expense_total(params)
    start_date = (Date.parse(params[:starting])) rescue Date.today
    end_date = (Date.parse(params[:ending]) rescue start_date
    Expense.where(date:start_date..end_date).sum("cost")
  end
end

Data Clump

This code has a data clump for date range, after doing the "extract class" refactoring the code looks like this.

class DateRange
  attr_reader :starting, :ending
  def initialiaze(starting:, ending: nil)
    @starting = Date.parse(starting) rescue Date.today
    @ending = Date.parse(ending) rescue @starting
  end

  def range
    starting..ending
  end

  def week_range
    starting..(starting + 6)
  end
end

class Sale < Persistence
end

class Expense < Persistence
end

class Foo
  def sales_total(params)
    range = DateRange.new(starting: params[:starting], ending: params[:ending]).range
    Sale.where(date:range).sum('cost')
  end
end

class Bar
  def weekly_sales_total(params)
    range = DateRange.new(starting: params[:starting]).week_range
    Sale.where(date:range).sum('cost')
  end
end

class Baz
  def expense_total(params)
    range = DateRange.new(starting: params[:starting], ending: params[:ending]).range
    Expense.where(date: range).sum("cost")
  end
end

Notice that the behavior is coalesced inside the class and is isolated in one place.

Message Chains

Foo, Bar and Baz have message chains i.e. they make call to the objects returned by Expense and Sale. Now these classes are coupled with the internal working of their dependencies.

When you are testing you should only need to mock the immediate collaborators of the object but in this case we'll have to mock the returned object. This generally means that we should extract pattern inside a method.

class DateRange
  attr_reader :starting, :ending

  def initialiaze(starting:, ending: nil)
    @starting = Date.parse(starting) rescue Date.today
    @ending = Date.parse(ending) rescue @starting
  end

  def range
    starting..ending
  end

  def week_range
    starting..(starting + 6)
  end
end

class Sale < Persistence
 def self.total(within:)
   where(date: within).sum("cost")
 end
end

class Expense < Persistence
 def self.total(within:)
   where(date: within).sum("cost")
 end
end

class Foo
  def sales_total(params)
    range = DateRange.new(starting: params[:starting], ending: params[:ending]).range
    Sale.total(within: range)
  end
end

class Bar
  def weekly_sales_total(params)
    range = DateRange.new(starting: params[:starting]).week_range
    Sale.total(within: range)
  end
end

class Baz
  def expense_total(params)
    range = DateRange.new(starting: params[:starting], ending: params[:ending]).range
    Expense.total(within: range)
  end
end

We have extracted the chain inside the total method.

Related: what you want to test is a trade off. You can only emulate / introduce so much reality inside your tests.

Rocky Mountain Ruby 2012 - To Mock or Not to Mock by Justin Searls

Coupling your tests to objects that are really far away then the test suite is going to get slow. If you couple your objects with slow things then your tests will get slower.

Using "Dependency Injection" we can mock the "roles" that the objects play rather than the class they are. which is how we should think when doing Object Oriented Programming.

Duplicate Code

Both Expense and Sale implement the same total method. This duplication can be eliminated by the "pull up method" refactoring. Monkey patching the Persistence class seems like a bad idea. So instead we pull out the logic inside a module and extend it from both the classes.

class DateRange
  attr_reader :starting, :ending
  def initialiaze(starting:, ending: nil)
    @starting = Date.parse(starting) rescue Date.today
    @ending = Date.parse(ending) rescue @starting
  end

  def range
    starting..ending
  end

  def week_range
    starting..(starting + 6)
  end
end

module Totalable
  def total(within:, date_field: :date, on: "cost")
    where({date_field => within}).sum(on)
  end
end

class Sale < Persistence
 extend Totalable
end

class Expense < Persistence
 extend Totalable
end


class Foo
  def sales_total(params)
    range = DateRange.new(starting: params[:starting], ending: params[:ending]).range
    Sale.total(within: range)
  end
end

class Bar
  def weekly_sales_total(params)
    range = DateRange.new(starting: params[:starting]).week_range
    Sale.total(within: range)
  end
end

class Baz
  def expense_total(params)
    range = DateRange.new(starting: params[:starting], ending: params[:ending]).range
    Expense.total(within: range)
  end
end

We have converted total to have a more generalized API. This can be seen as "Speculative Generality" but until the methods are small this is a good trade off as the flexibility is much more than the added complexity.

Link to the original talk

Do check out my other posts in the series :)

React Day Berlin 2018 - The Lonely and Dark Road to Styling in React -- Sara Vieira

Chirag Jain — Thu, 20 Dec 2018 18:42:23 +0000

This is my second post in the talk notes series. You can check out the first one here.

CSS is hard

Link tags

Blocks rendering, only ship the CSS you need i.e. critical CSS

BEM (Block Element Modifier)

.block__element—modifier

Pros

Easy to setup
Framework/Library agnostic
Fixes some specificity issue
Rigid Structure

Cons

Naming is hard
Need to memorise the rules and strictly follow them

Preprocessors

Pros

Nesting
Variables
SSR just works

Cons

Over Nesting
More dependencies
Makes it hard to author library → to modify, you need to run the preprocessor
Not optimised for a component based workflow
No dynamic styles based on runtime values

CSS Modules

Write normal CSS with classes and use them inside your components. In the end these will be replaced by random class names.

Use it via PostCss (Babel for CSS)

Pros

Can use all new CSS features
Autoprefixes CSS
SSR just works
More component based and maintainable

Cons

Unreadable class names
More dependencies
Needs to be paired with a pre-processor for variable support
Global class names can be abused

CSS-in-JS (Styled Components)

Just react components. No SSR support out of the box which can be mitigated by using Razzle (It will extract all the styles and give you style tags to insert into the HTML)

Pros

Dynamic styles (based on state and prop of the component)
Theming is super easy using the ThemeProvider component, It will pass the theme as a prop to the child component.
Can still use the cascade but the whole point is that the styles for your component are only for that component.
No more specificity problems.
Autoprefixes everything
No need to worry about naming things

Cons

Needs to change the way you think about CSS
Another thing to learn across the team
The library you are using might only support object based CSS
SSR is hard to implement yourself

There is nor Right / Wrong answer. Context / use-case matters when choosing a solution. For example: For prototyping you might want to use tachyons while if you need scalability you would probably go for something different or make something over it to avoid repeating classnames.

Link to the original Talk

If you liked this do check out other posts in the series :)

Clojure Conj 2018 - Maybe Not -- Rich Hickey

Chirag Jain — Wed, 19 Dec 2018 18:07:33 +0000

This is my first post in the series. Rich Hickey is the creator of the Clojure Language. He is widely known for his clear thinking and unique approach towards software. These are my notes for his talk titled "Maybe Not", which he gave at at Clojure Conj 2018.

NULL

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. — Tony Hoare

Why are nulls / options used?

Optional requirements
- Clojure mitigates this by providing varaidics and kw-args (keyword args)
Conditional provision (returns)
Managing partial information (aggregates)

Maybe ?

If we make an arguments optional or make the return value optional by wrapping them in a maybe, both break all the API whereas It should be compatible change as we are making things optional.

Maybe/Either are not type system's or/union type, rather evidence of lack of first-class union types

Kotlin solves this by providing Nullable and Non-nullable types

Dotty (Successor to Scala): Union types are dual of intersection types. Values of type A | B are all values of type A and all values of type B.

| is commutative i.e. A | B is the same type as B | A

Aggregate → Flock/Herd that moves together

Maps vs Records/Fields/Product Types

Maps
- maps are mathematical functions
- Simplest functions in programming
  - Key → value
  - No code, No categories
Records
- Place-oriented programming
- Even with named fields
  - Names are not first class indices
  - thus are not functions
- Product types complect meaning and place
  - data Person = Person String String there's no way to tell what the first string stores and what does the second
But records are more restrictive (which is good)
spec/keys
- Independent, reusable attributes, RDF-style
- aggregate attributes to form a schema

Optionality and aggregates

When something is missing from a set → leave it out
Maps are enumerable, so if we leave out what we don't know, then their are no empty slots

Context

RDF style attributes are context free

No maybes → Either you know a model or you don't.

A name is always a string, the fact that you know it or not is an orthogonal idea and binding them together using a type is wrong

It's a mistake to put optionality in aggregate definitions because unlike args and returns there is no usage context.

We want

Maximum schema re-use, as defining multiple context specific schemas for the same idea leads to disconnect between the various schema definitions.
Support symmetric request/response
Information building pipelines

Schemas are deep

schemas can nest
attribute values can be collections
optionality specs should be deep

Fix

Split apart the schema(shape) and the selection(optionality for current context)

The schema will only mentions the structure not optionality

The selection will described in the method signature, so that the it can be clearly specified what parts of the schema are required.

Separate requiring attribute from requirements of the attribute, example: address is optional but if address is provided then the zip-code is required

This system is flexible to allow you to specify your assumptions of the incoming data while making the default to allow everything.

Make systems that are extensible, that you can change and enhance over time

Link to the original talk

If you like this do check out the other posts in the series :)