Forem: Sai Krishna

Launching Portfolio 🥳 🎊 🎉

Sai Krishna — Sun, 26 Jul 2020 12:45:23 +0000

Finally launched my personal website and blog, designed and developed myself. Built with Gatsby, React and flavor of SASS

saikrishna.dev

Would love the DEVCommunity Feedback/Suggestions ❤️

What's your checklist and suggestions for starting a new tech project/blog?

Sai Krishna — Tue, 26 May 2020 02:56:14 +0000

I am working on a blog post that details the do's, dont's and provides few tips for starting a new tech project/blog - to help boost confidence for those with imposter syndrome or feel they have it(like me 😉) and scrap the projects in the initial phase itself.

I thought it would be best for the readers to add in the community input which is a vast knowledge.

I will give you the credits by linking your profile. I respect your privacy, if you would like to stay anonymous, please mention so by adding anonymous: true at the end of your comment.

Thank you so much for helping me and the community.
Cheers!

Do you feel more productive at the office or at home? Why?

Sai Krishna — Mon, 25 May 2020 07:51:41 +0000

Cover Image: Google maps page of the organization I work for, Codebrahma - I miss this beautiful view.

It's been more than 2 months since most of us started work from home.

I am not feeling much difference in my productivity, maybe because my travel time was less (15-20min) and I go by bicycle which I am now compensating for by walking.

For those who are spending hours on road especially with Bangalore's traffic, WFH must be great and a little relaxing.

I am definitely missing coffee time and Table Tennis and a lot of other fun activities at the office. And yeah I definitely miss my wonderful colleagues.

How to Smoothly Render Images in React App?

Sai Krishna — Mon, 09 Mar 2020 05:00:23 +0000

Improve your web apps UX by enhancing image render with React's onLoad event and simple SCSS.

This article is cross-posted on Codebrahma and Medium

Let's cut to the chase. The GIF below shows what we are going to achieve by the end of this post.

Default Image Rendering vs Smooth Image Rendering using render-smooth-image-react

Here is the Completed Component - RenderSmoothImage.

Final Code — RenderSmoothImage — React Component

I have published this as an npm package render-smooth-image-react. The source code is available on GitHub.

Little Back Story

I recently started working on a media-heavy app. Everything was cool until I noticed a bunch of images rendering poorly. Which looked something like this.

Example: Poor image rendering (printing)

For a moment I thought, “Did I end up building a 🖨 printer simulator app?”

Overall customer satisfaction will take a hit with such poor loading UX (even if the rest of the app is great). This is especially true for media-heavy apps.

Alright, Let’s see what we can do to fix this.

Load and Fire 🔫

Let the browser download the image and render it.

The perfect moment to render an image is after downloading completely. Till then we just show a loader/placeholder and hide the image.

We can achieve this by using React’s onLoad event on the image tag. You can read more about React.js events here.

  <img onLoad={'callbackAfterImageIsDownloaded'} />

Code it

We will create a functional component and use hooks to maintain a couple of states. If you are new to React Hooks, You can learn more here.

  // RenderSmoothImage.jsx

  function RenderSmoothImage({src, alt}) {
    const [imageLoaded, setImageLoaded]=React.useState(false);

    return (
      <div className="smooth-image-wrapper">
        <img
          src={src}
          alt={alt}
          className={`smooth-image image-${
            imageLoaded ? 'visible' :  'hidden'
          }`}
          onLoad={()=> setImageLoaded(true)}}
        />
        {!imageLoaded && (
          <div className="smooth-preloader">
            <span className="loader" />
          </div>
        )}
      </div>
    )
  }

/** styles.css */

  .smooth-image {
    transition: opacity 1s; 
  }
  .image-visible {opacity: 1}
  .image-hidden {opacity: 0}

Here, we maintain a state imageLoaded defaults to false. Which will then be set to true, once the image is downloaded. We use the onLoad event to trigger this.

Then we use imageLoaded state to conditionally add classes to the img tag, image-visible vs image-hidden. We can add transitions/animations to make it smoother. Please refer to the linked Gist at the top for complete styles.

That’s it! No more printer simulators on the page.

What if Image Download Fails / Invalid Src?

Image for alternate text with image tag

By using the alt attribute we can show alternate text for the image. However, the default icon and styling isn’t too great. To fix this we can display custom alt text.

  // RenderSmoothImage.jsx

  function RenderSmoothImage({src, alt}) {
    .....
    const [isValidSrc, setIsValidSrc] = React.useState(!!src);

    return (
      <div className="smooth-image-wrapper">
        {isValidSrc ? (
          <img
            ....
            onError={() => setIsValidSrc(false)}
          />
        ) : (
          <div className="smooth-no-image">{alt}</div>
        )}
        {isValidSrc && !imageLoaded && (
          <div className="smooth-preloader">
            <span className="loader" />
          </div>
        )}
      </div>
    )
  }

    /** styles.css */
    ......
    .smooth-no-image {
      background-image: linear-gradient(90deg,#ccc,#999,#ccc);
      color: #fff;
    }

There you go,

Customized Alternate Text for Image

You can style the Alternative text any way you want.

I made things easy for you and published a light-weight npm package render-smooth-image-react.

Thank you for reading this post, This is Sai Krishna Prasad, a self-taught and passionate web developer. Signing off Bubye….. until next time.

Understanding Procs, Lambdas, and Blocks in Ruby - Part 2: All Why?s Explained

Sai Krishna — Mon, 24 Feb 2020 12:46:09 +0000

In the first part of this article, We learned about what Procs, Lambdas, and Blocks are? If you haven’t read it, I strongly recommend you to read Part 1: All what?s Answered, before continuing.

In this part, let’s explore why we need Procs, Lambdas, and Blocks in the first place and how helpful using them with few examples and use cases.

Let’s get started…

Why Blocks?

Recap: A block is a piece of a code that is either enclosed within curly braces {} or a do..end. It is similar to a method but neither belongs to any object nor it has a name.

To answer why blocks? and to understand the necessity of using them, we should answer one more question — Can the identifier/reference of the ruby method be used as a first-class value or passed with no additional action?

No. Ruby methods are not First-Class Functions unlike in few other languages, say Javascript.

The identifier of a regular “function” in Ruby (which is really a method) cannot be used as a value or passed. It must first be retrieved into a Method or Proc object to be used as first-class data. — wiki

To be used as a first-class value, It must first be captured into a Method or Proc object first.

  # Retrieving method reference into Method object
  def some_method
    puts "Called by Reference"
  end

  method_reference = method(:some_method)
  # <Method: main.some_method>

  # Calling the method using its reference
  def some_other_method(method_ref_argument)
    # Do something before
    method_ref_argument.call
    # Do some other things
  end

  some_other_method(method_reference)
  # returns "Called by Reference"

On the other hand, Blocks can be created “on the go” and we need not worry about reference. Let’s try to achieve the same as above with blocks.

  # Block - No method reference capturing bullsh*t

  def some_other_method(&block_argument)
    # Do something before
    block_argument.call
    # Do some other things
  end

  some_other_method { puts "I am Block! and you are?" }
  # returns "I am Block! and you are?"

With this approach, we do not need to create a method each time we want some custom things to happen in different methods.

Well, can blocks be assigned/referenced at all? Yes, which we call as procs and lambdas — don’t worry about this now, we will discuss in later sections.

P.S. If you are curious about the & symbol prepended to the method argument, here is a beautifully written article that explains it.

Do you have a point?

One method can be made to work in different means by injecting some custom code within the method from outside.

In other words, Using the block gives back control to the programmer.

Let’s take a simple use-case…

A Customer Support System for a service provider, to manage support tickets that are raised by customers. Let’s just focus on ticket status and ignore other features.

A Ticket has one among open, on_hold or closed status. We have an API endpoint to mark the respective status for the tickets.

Usually, in our controller, we implement as below

  class TicketsController < ApplicationController
    .....

    def mark_open
      if @ticket.update(status: "open")
        # request response logic
      else
        # error handler
      end
    end

    def mark_on_hold
      if @ticket.update(status: "on_hold")
        # request response logic
      else
        # error handler
      end
    end

    def mark_closed
      if @ticket.update(status: "closed")
        # request response logic
      else
        # error handler
      end
    end

    ......
  end

We can notice the repeated code for each method to handle the response and errors. The primary action of these methods is to update status let alone handle requests and responses.

By using blocks we can abstract the request-response and error handling to a new method keeping the actions clean and more readable.

  class TicketsController < ApplicationController
    .....

    def mark_open
      status_manager do
        @ticket.update(status: "open")
      end
    end

    def mark_on_hold
      status_manager do
        @ticket.update(status: "on_hold")
      end
    end

    def mark_closed
      status_manager do
        @ticket.update(status: "closed")
      end
    end

    def status_manager
      is_status_changed = yield

      if is_status_changed
        # request response logic
      else
        # error handler
      end
    end

    ......
  end

Okay, so where can I use Blocks?

The status_manager from our Ticketing app use case is one of many use cases where blocks can be helpful.

For instance, consider a few array methods Array#each, Array#map, Array#select, etc., — all these methods accept a block.

  ["procs", "lambdas", "blocks"].each do |concept|
    puts "Ruby - #{concept}"
  end

We can do the same with a for loop or a while loop, literally any iterator. But, that’s a lot of code — In other terms, it is imperative programming. You can learn more about imperative, declarative and other programming paradigms here.

I suppose, by now we have our answer to “Why Blocks?”.

There is one limitation with blocks though. We can’t assign a block to a variable. Let’s say we want to implement similar functionality in more than one method. We have to send the block to each of the methods individually — this leads us to the next section “Why Lambdas?”.

Why Lambdas?

Recap: A Lambda is very similar to a block and is also called an anonymous function. But, unlike blocks *lambdas are objects and can be assigned to variables with a special syntax.*

Using Lambdas and Procs, we can store a block in a variable and reuse. To be more specific, blocks are useless without a method call. Also, lambdas can be called repeatedly without having to rewrite them every time, unlike blocks.

Lambdas give more flexibility than methods.

  greeter = -> (greeting, name) { greeting + " " + name }

  greeter.call("Dear", "Ruby Developer")
  # returns "Dear Ruby Developer"

In simpler terms, lambda is like any other method that takes a block with an exception being assignable to variables.

Let’s consider the Ticketing System again, this time will update our blocks to a single lambda.

  class TicketsController < ApplicationController
    ......

    def mark_open
      status_manager("open")
    end

    def mark_on_hold
      status_manager("on_hold")
    end

    def mark_closed
      status_manager("closed")
    end

    status_updater = -> (ticket, status) do
      ticket.update(status: status)
    end

    def status_manager(status)
      is_status_changed = status_updater.call(@ticket, status)

      .....
    end

    ......
  end

Let’s take another use case and see how lambdas can be helpful.

This time we assume a gem for API service and we have a method called callback that is triggered for either success or failure responses. We need this method to be customizable and allow the gem user to define its functionality.

  # gem code

  class SomeAPIServiceController
    .....

    def callback(on_success: on_failure:)
      if success
        on_success.call(res)
      else
        on_failure.call(err)
      end
    end

    .....
  end

We can use blocks, but we are limited to use only one block per method call. So, how can we pass multiple blocks to this callback method?

Wait for it, Wait for it, lambdas lambdas yessss, lambdas to the rescue.

  success_callback = -> (response) { # Do something with response }
  failure_callback = -> (error) { # Do something with error }

  callback(
    on_success: success_callback,
    on_failure: failure_callback
  )

With that we are left with the final question in our Blocks, Lambdas and Procs Exploration — Why Procs?

With no further delay, let’s unravel the procs.

Why Procs?

Recap: Procs, the shorthand for Procedure, is a very similar concept to lambdas. Procs are instances of ruby Proc class.

Lambdas are a special case of Procs and are a proc object. There is no dedicated Lambda class. If you have understood the why Lambdas? section, we already have our answer to why Procs?

Also, we can use Procs instead of lambdas in every possible use-case, but lambdas and procs have their differences which I explained in Part1: All’s What?s Answered.

Procs are full-fledged Objects and have all the abilities that an object does, while blocks on the other hand does not.

Since lambdas and procs are objects we can do all the crazy stuff that an object can do.

  proc_object = Proc.new { puts "I am Proc!" }
  #<Proc:0x00007fc1ccfdcb50@(irb):9>

  proc_object.call
  # "I am Proc!"

Well, that concludes our journey.

That’s too much man 🤓

Let’s do a quick summary and play with our cute little 🐶 buddy….

A method can neither be passed as argument nor be returned from another method (methods in ruby are not first-class functions).
Blocks are useless without method calls and have to be rewritten every time.
Blocks give back control to the programmer.
Procs are full-fledged Objects.
Lambdas are a special case of procs.
Lambdas are more flexible than methods.
Using blocks, lambdas, and procs. One method can be made to work in different aspects by injecting some custom code within the method from outside.

References

Any difference between First Class Function and High Order Function
Mastering Ruby Blocks in Less Than 5 Minutes
The Ultimate Guide to Blocks, Procs & Lambdas
And a lot of bits and pieces from mother google.

I am a beginner to ruby, so please let me know if I have missed or misunderstood something above. I look forward to your suggestions and feedback in the comments section below.

I hope this article helped you understand procs, lambdas and blocks better.

Thank you for reading this post, This is Sai Krishna Prasad, a self-taught and passionate web developer. Signing off Bubye….. until next time.

Understanding Procs, Lambdas, and Blocks in Ruby - Part 1: All What?s Answered

Sai Krishna — Sun, 23 Feb 2020 13:27:26 +0000

I recently started learning ruby as part of my journey to be a full stack developer. I am using rubymonk.com which is a really good source for an absolute beginner. After a few smooth moving lessons and problems, I landed on the Procs and Lambdas section. I had a hard time understanding procs, lambdas, and blocks.

After spending a good amount of time with them, I finally have some clarity on how procs and lambdas work. Now I want to share my knowledge so that others will have an easier time understanding them.

I would like to explain procs and lambdas with two W questions, What? and Why? Let’s start with a few what?’s.

What are the Blocks?

Before jumping into procs and lambdas, let’s get a clear picture of what blocks are.

A block is a piece of a code that is either enclosed within curly braces {} or a do..end. It is similar to a method but neither belongs to any object nor it has a name. Syntactically {} is used for one-liner blocks and do..end for multi-line blocks. Let’s take a look at the following snippet to see the difference.

  concepts = ['blocks', 'lambdas', 'procs']

  # One liner {} blocks
  concepts.each { |concept| puts "Ruby: #{concept}" }

  # Multi-line do..end blocks
  mastered_concepts = ['blocks', 'procs']

  concepts.each do |concept|
    if mastered_concepts.include?(concept)
      puts "I already mastered #{concept}"
    else
      puts "Yet to learn this #{concept}"
    end
  end

The Implicit Block with its friendly keyword yield

Blocks are also called closures in other languages. Blocks can be passed to a method either implicitly or explicitly. Only one block can be passed to a method.

Implicit blocks are nameless and not necessarily we list them in the method arguments.

  def implicit_block_method
    yield
  end

  implicit_block_method do
    puts "I am an implicit block, also I am nameless!"
  end

Implicit Blocks can be invoked using the keyword yield. They can accept arguments too, if necessary. In other terms, blocks are just an anonymous chunk of code that is passed to a method to perform something.

  def my_skills
    yield "procs"
    yield "blocks"
  end

  my_skills { |skill| puts "I am skilled in Ruby #{skill}" }

One thing to note here is that yield is just a keyword that invokes the block as many times it is used inside a method.

The Explicit Block and its name everything syndrome

Explicit blocks are named and should be included in the arguments list.

The block should be the last argument that a method accepts. Explicit Blocks can be invoked by using the .call method on the block name.

  def explicit_block_method(*argument_list, &block_name)
    block_name.call
  end

  explicit_block_method do
    puts "I am an explicit block, My name is block_name"
  end

An Example with multiple arguments.

  def block_caller_method(normal_argument, &block_as_argument)
    puts "I am #{normal_argument} inside method"
    block_as_argument.call "argument for block"
  end

  block_caller_method("Normal argument") do |argument_for_block|
    puts "Inside block and received #{argument_for_block}"
  end

Does a block return?

Yes, Blocks can return, just like methods. let’s talk about this in code.

  ['ruby', 'javascript', 'python', 'java'].select do |language|
    language.length == 4
  end

  # returns ['ruby', 'java']

Here we are performing Array#select and passing in a block to specify our condition. This will return a new array with languages that have 4 character long names.

Safeguard your method with “block_given?”

Huff!! That’s a lot. There is one last thing we should know about blocks.

What if no block is passed to a method but we are expecting one, Ruby throws an error LocalJumpError if yield is used and NoMethodError if the method call is called on the block.

  def expecting_block
    yield
  end

  expecting_block
  # LocalJumpError (no block given (yield))

  def me_to_expecting_block (&block_name)
    block_name.call
  end

  me_to_expecting_block
  # NoMethodError (undefined method `call' for nil:NilClass)

To fix this we just need to check if the block is given or not, using block_given?.

  def is_block_given
    if block_given?
      yield "Yes"
    else
      puts "I am hurt :-/, I thought you would give me a block!"
    end
  end

  is_block_given { |status| puts "#{status} it is." }
  # Yes it is.

  is_block_given
  # I am hurt :-/, I thought you would give me a block!

What are Lambdas?

Now that we have some knowledge on blocks let’s move on to lambdas. Understanding blocks makes understanding lambdas much easier.

Lambda is the eleventh letter in the Greek alphabets…. Whaaaat? Oh, Shoot!! We are not talking about this(λ) lambda. Let’s get to know the lambdas in ruby then.

A Lambda is very similar to a block and is also called an anonymous function. But, unlike blocks lambdas are objects and can be assigned to variables with a special syntax.

We can create lambda by using the keyword lambda or the -> stab operator. The lambdas created with -> stab operator are also called a stabby lambda.

  # lambda block
  lambda = lambda { puts "I am a block declared with lambda" }

  # -> block
  stabby_lambda = -> { puts "Alternate syntax, stabby lambda" }

The Proc class

When we created a lambda you might have observed something weird.

  lambda = lambda { puts "A new lambda has been created." }

  # <Proc:0x00007ff3758d7b68@(irb):54 (lambda)>

The lambda is created as a new instance of the class Proc. Yes, This is fine. Because lambda’s do not have a dedicated class they are part of the class Proc. You can check this by calling the method class on the lambda.

  lambda = lambda { puts "Proc is my class!"}

  lambda.class
  # returns Proc

Proc is the short form for Procedure, We will talk more about procs in the next section. You can happily ignore it for now.

Arguments in lambda

Lambdas also accept arguments, But the syntax for this is dependent on whether you’ve declared the lambda with the lambda keyword or with the -> operator.

  lambda = lambda { |arg| puts "I am lambda #{arg}." }

  stabby_lambda = -> (arg) { puts "I am also lambda #{arg}." }

  lambda.call "Argument"
  # I am lambda Argument.

  stabby_lambda.call "Argument"
  # I am also lambda Argument.

Lambdas can also be called in multiple ways.

  lambda = lambda { |name| puts "Hello #{name}!" }

  lambda.call "Ruby"
  lambda.("Ruby")
  lambda["Ruby"]
  lambda.=== "Ruby"

  # all of them prints the same, "Hello Ruby!"

Lambda in action

Lambdas can be stored in a variable and can be passed to any method as an argument.

  double_it = -> (num) { num * 2}

  [1,2,3,4,5].map(&double_it)
  # returns [2,4,6,8,10]

Did you notice the &(ampersand) symbol appended to double_it?. That’s a short form for calling the methodto_proc on the variable we stored. Also, & is the one responsible for converting a lambda / proc to block. Usually, Array#map expects a block, not a lambda / proc.

&double_it is equivalent to double_it.to_proc.call

That’s all we need to know about lambdas for now. Let’s move on to procs.

What are Procs?

Proc, the shorthand for Procedure, is a very similar concept to lambdas. Lambdas are a subpart of Procs. As we have already seen, the class for lambda is a Proc. Like lambdas, Procs are objects of ruby Proc class. Though lambdas and procs are similar, they also have their differences. But we will get to that in a bit.

We can create a proc with a new instance of the Proc class Proc.new or with the keyword proc which is again the same as Proc.new and is just syntactical sugar. Let's create some procs…

  # Proc.new block
  proc = Proc.new { puts "I am proc, New instance of Proc class." }

  # proc block
  new_proc = **proc** { puts "I am a proc with keyword!" }

Calling procs and passing them arguments is very similar to lambdas, so I am not going to spend a whole lot of time on it. We should say lambdas are similar to procs. Just call the method class on lambda and proc and it answers everything. Both returns Proc.

  lambda = -> {}
  proc = proc {}

  lambda.class
  proc.class

  # both returns Proc

Also to show that lambdas and procs are objects, call superclass method on the class Proc . It returns Object.

  Proc.superclass

  # returns Object

Procs vs Lambdas

There are a couple of important differences between procs and lambdas specifically Arguments Handling and Return statement behavior.

Arguments Handling, We have a very strict officer here. Guess Who? Yeah, you guessed it right. It’s officer Lambda.

Lambdas throw an exception (ArgumentError) when an incorrect number of arguments are passed.

  lambda = -> (arg1, arg2) { puts "I am strict, #{arg1} and #{arg2}" }
  lambda.call("Tough")

  # ArgumentError (wrong number of arguments (given 1, expected 2))

While Procs aren’t worried about them at all. If an extra argument is passed procs will ignore it. If fewer than expected arguments are passed procs will replace all the missed ones with nil.

  proc = proc { |arg| puts "I am too lazy to care about #{arg}" }
  proc.call

  # I am too lazy to care about

Though procs don’t throw an exception for the number of arguments, other cases could raise exceptions. For example:

  addition = proc { |num1, num2| num1+num2 }

  # passing only 1 argument
  addition.call(1)
  # TypeError (nil can't be coerced into Integer)

  # passing no arguments
  addition.call
  # NoMethodError (undefined method `+' for nil:NilClass)

Here, proc is not worried about arguments and replaces the missed one with nil. Programmatically nil can’t be added to Integer. So, we get a TypeError or NoMethodError as above.

Just to be on the safer side, always set default values to arguments. If default values cannot be set make sure to pass the required number of arguments or have error handling blocks.

  addition = proc { |num1=0, num2=0| num1+num2 }

  addition.call
  # returns 0

  addition.call(2)
  # returns 2

Return statement Behavior, lambdas, and procs behave in a very different manner when comes to return statements.

Lambdas will return from the executing block/lambda and the further execution will continue as usual.

  def return_from_lambda
    lambda = lambda { **return** "I will just return from lambda!" }

    puts "I will execute, before lambda return!"
    puts "#{lambda.call}"
    puts "I too will execute, after lambda return!"
  end

  return_from_lambda

  # I will execute, before lambda return!
  # I will just return from lambda!
  # I too will execute, after lambda return!

While procs will return from the currently executing context/method.

  def proc_return_method
    proc = proc { **return** "I will return the method!" }

    puts "I will execute, before proc return."
    proc.call
    puts "I will never execute, after proc return!"
  end

  proc_return_method

  # prints "I will execute, before proc return!"
  # returns "I will return the method!"

There is one thing that we must know while handling returns with proc. As I mentioned proc will return from the method. If we just create a proc and call it without any context ruby raises a LocalJumpError as there is nothing to Jump back after returning from the current context.

  error_proc = proc { return "I will raise exception" }
  error_proc.call

  # LocalJumpError (unexpected return)

Aaannnddddd!!! We are done.

In Nutshell

Blocks

Block is a piece of code enclosed between {} or do..end.
Block neither belongs to any object nor it has a name.
Blocks can return just like methods.

Lambdas

Lambdas are objects, unlike blocks. Also, lambdas have a name and can be assigned to a variable for later use.
Lambda can be created either with the lambda keyword or with the -> stab operator.
Lambdas are strict in terms of arguments.
Lambdas are a part of the Proc class.
Lambda returns from current lambda/block.

Procs

Procs are also objects and have a name.
Proc can be created by Proc.new or with keyword proc.
Procs aren’t worried about the number of arguments passed.
Proc returns from a method/current context.
Blocks, Lambdas, and Procs are all Closures.

Well well, well!!! We made it! Now we have answers to most whats on Procs, Lambdas, and Blocks.

In the next part of this article, I will talk about next W “why?” with a few examples demonstrating why we need procs and lambdas in the first place.

I am a beginner to ruby, so please let me know if I have missed or misunderstood something above. I look forward to your suggestions and feedback in the comments section below.

I hope this article helped you understand procs, lambdas and blocks better.

Thank you for reading this post, This is Sai Krishna Prasad, a self-taught and passionate web developer. Signing off Bubye….. until next time.