So lets start with the template that is needed to add your application to the Ubuntu's desktop apps entry. All you need is:

1. Create a launcher for your application with .desktop file extension

2. Place your .desktop file inside ~/.local/share/applications directory or if you want it to be visible to all users then place it under /usr/share/applications.

3. Your .desktop file should have following contents:

# <application_name>.desktop

[Desktop Entry]
Name=Application Name
Comment=A short description of the application
Exec=/full/path/to/application/executable
Terminal=false
Type=Application
Icon=/full/path/to/icon-file

In this example we are going to use RubyMine as an example

1. download the rubymine-xx.tar.gz

2. Extract it and place it under your preferred place, I am placing it under ~/.local/.share directory.

3. And now create a rubymine.desktop file inside ~/.local/share/applications

touch ~/.local/share/applications/rubymine.desktop

4. Now we edit this file with following content

[Desktop Entry]
Name=RubyMine
Comment=RubyMine IDE
Exec=~/.local/share/rubymine/bin/rubymine.sh
Terminal=false
Type=Application
Icon=~/.local/share/rubymine/RMlogo.svg

That's it, you should now be able to see your RubyMine application listed in your "Show Applications" list. If it is not, try restarting your PC and it should be there.

Test-Driven Development (TDD) is a software development methodology that focuses on writing tests before writing the actual code. In TDD, you start by creating a test case that defines the expected behavior of a particular piece of code. Then, you write the code to make the test pass. TDD follows a cycle known as the "Red-Green-Refactor" cycle:

1. Red: You begin by writing a failing test case (the "Red" phase) that specifies the desired functionality.

2. Green: You then write the minimal code required to make the test pass (the "Green" phase). This ensures that the code meets the specified requirements.

3. Refactor: After the test passes, you can refactor the code to improve its quality while keeping the test passing. This maintains the code's correctness as you make changes.

Before diving into our inaugural TDD Go application, it's crucial to emphasize another vital facet of TDD: setting up source control, such as Git. Git plays a pivotal role by allowing you to commit the latest functional iteration of your TDD process. This safeguards your progress, enabling you to revert to a previous version and embark on a fresh refactoring journey with confidence.

Lets start TDD with our hello world program again

Prerequisite:

• Create new project folder e.g: hello-world

• Create 2 files inside it hello_test.go and hello.go, its Ok if the contents are empty

• Generate go module with go mod init hello.

And you should be ready to follow along.

RED

Open your hello_test.go file in your editor/IDE and write a test case first:

package main

import "testing"

func TestHello(t *testing.T) {
    t.Run("Say hello to John Doe", func(t *testing.T) {
        got := Hello("John Doe")
        expected := "Hello, John Doe"

        if got != expected {
            t.Errorf("expected %q but got %q", expected, got)
        }
    })
}

Run the go test -v and see it failing

 go test -v                                                                              ─╯
# hello [hello.test]
./hello_test.go:7:10: undefined: Hello
FAIL    hello [build failed]

GREEN

Open your hello.go file in editor and create a Hello function because our test case is complaining Hello is undefined.

// hello.go

package main

func Hello() string {
}

Run the test again and see another failure.

go test -v                                                                              ─╯
# hello [hello.test]
./hello.go:4:1: missing return
./hello_test.go:7:16: too many arguments in call to Hello
        have (string)
        want ()
FAIL    hello [build failed]

Running your tests at each step is essential to ensure that your test cases do not unexpectedly pass when they shouldn't.

Lets write enough code to make this test GREEN

// hello.go

package main

func Hello(name string) string {
    return "Hello, " + name
}

Run your test case again and it should pass this time.

 go test -v                                                                              ─╯
=== RUN   TestHello
=== RUN   TestHello/Say_hello_to_John_Doe
--- PASS: TestHello (0.00s)
    --- PASS: TestHello/Say_hello_to_John_Doe (0.00s)
PASS
ok      hello   1.417s

Source Control

💡At this point because we have workable version of the code, lets commit our changes to git git commit -am "Function to say hello to John Doe"

REFACTOR

Now that our test case is passing, let's refactor our code.

// hello.go

// ...

const englishHelloPrefix = "Hello, "

func Hello(name string) string {
    return englishHelloPrefix + name
}

Run the test again go test and everything should still pass. It might seem silly to make that change right now, trust me we need it.

In this step, we've extracted the "Hello, " message into a constant. It's worth considering the use of constants to convey the meaning of values and, in some cases, to optimize performance.

💡As a final step, because now we have all steps satisfied RED, GREEN, REFACTOR, it is time to commit your changes to git and also push it to the git repository.

Continue to add features with TDD in mind

Requirement: if name is "" empty string, return Hello, world instead.

RED

func TestHello(t *testing.T) {
    t.Run("Say hello to John Doe", func(t *testing.T) {
        got := Hello("John Doe")
        expected := "Hello, John Doe"

        if got != expected {
            t.Errorf("expected %q but got %q", expected, got)
        }
    })

    t.Run("say 'Hello, world' when an empty string is given", func(t *testing.T) {
        got := Hello("")
        expected := "Hello, world"

        if got != expected {
            t.Errorf("expected %q but got %q", expected, got)
        }
    })
}

Run the test go test it should fail with this message hello_test.go:20: expected "Hello, world" but got "Hello, " .

GREEN

const englishHelloPrefix = "Hello, "

func Hello(name string) string {
    if name == "" {
        name = "world"
    }

    return englishHelloPrefix + name
}

Run the test go test again and it should pass.

💡commit your code to git

REFACTOR

There is nothing to refactor in the actual program, but we can extract duplicate code from our test case to keep it DRY (Don't Repeat Yourself)

func TestHello(t *testing.T) {
    t.Run("Say hello to John Doe", func(t *testing.T) {
        got := Hello("John Doe")
        expected := "Hello, John Doe"

        assert(t, expected, got)
    })

    t.Run("say 'Hello, world' when an empty string is given", func(t *testing.T) {
        got := Hello("")
        expected := "Hello, world"

        assert(t, expected, got)
    })
}

func assert(t testing.TB, expected, got string) {
    t.Helper()

    if expected != got {
        t.Errorf("Expected %q but got %q", expected, got)
    }
}

Run your test again and it should still pass.

We have created assert function that expects:

• testing.TB object as first argument, this will allow us to pass either *testing.T testing or *testing.B benchmarking.

• we also said this is a helper function by calling t.Helper(). We did this because if the test case fail, it will show the exact line number where it failed from the actual test function rather then showing line number of the assert() function. You can change one of your test case with wrong assertion and see it for yourself by keeping and removing t.Helper() from assert() function.

\>💡commit your changes to git, and push your code to git repo

Enjoying so far? 😍lets keep moving forward.

Requirement: our Hello function should support additional parameter to specify the language of the greeting. Example Hola, in Spanish, Bonjour, in French, and you can choose your own language, example नमस्ते, (Nameste) in Nepali.

RED

func TestHello(t *testing.T) {
    // old code

    t.Run("greeting in Spanish", func(t *testing.T) {
        got := Hello("John", "es")
        expected := "Hola, John"

        assert(t, expected, got)
    })
}

Run the test and it should fail. BTW because go is Statically typed language, if your Editor/IDE is correctly configured, you should see compiler yelling at you at this point.

./hello_test.go:21:24: too many arguments in call to Hello
        have (string, string)
        want (string)
FAIL    hello [build failed]

GREEN

Add lang string parameter to your Hello() function

const englishHelloPrefix = "Hello, "

func Hello(name, lang string) string {
    if name == "" {
        name = "world"
    }

    return englishHelloPrefix + name
}

Run the test

go test                                                                                 ─╯
# hello [hello.test]
./hello_test.go:7:16: not enough arguments in call to Hello
        have (string)
        want (string, string)
./hello_test.go:14:16: not enough arguments in call to Hello
        have (string)
        want (string, string)
FAIL    hello [build failed]

As you can see, by writing TDD you know exactly when your code breaks, lets fix our old tests

    t.Run("Say hello to John Doe", func(t *testing.T) {
        got := Hello("John Doe", "") // added "" as second argument
        expected := "Hello, John Doe"

        assert(t, expected, got)
    })

    t.Run("say 'Hello, world' when an empty string is given", func(t *testing.T) {
        got := Hello("", "") // added "" as second argument
        expected := "Hello, world"

        assert(t, expected, got)
    })

    t.Run("greeting in Spanish", func(t *testing.T) {
        got := Hello("John", "es")
        expected := "Hola, John"

        assert(t, expected, got)
    })

Run the test again

go test                                                                                 ─╯
--- FAIL: TestHello (0.00s)
    --- FAIL: TestHello/greeting_in_Spanish (0.00s)
        hello_test.go:24: Expected "Hola, John" but got "Hello, John"
FAIL
exit status 1
FAIL    hello   0.804s

Now you should see, we are expecting Hola, John but our function is returning Hello, John. Lets fix it.

const englishHelloPrefix = "Hello, "

func Hello(name, lang string) string {
    if name == "" {
        name = "world"
    }

    if lang == "es" {
        return "Hola, " + name
    }

    return englishHelloPrefix + name
}

Run the test and you should see everything passing, 🎉

💡commit your changes to git

REFACTOR

Let's extract Spanish greeting to it's own constant and also extract lang value to its own constant.

const (
    englishHelloPrefix = "Hello, "
    spanishHelloPrefix = "Hola, "
)

const spanish = "es"

func Hello(name, lang string) string {
    if name == "" {
        name = "world"
    }

    if lang == spanish {
        return spanishHelloPrefix + name
    }

    return englishHelloPrefix + name
}

Run the test again and everything should pass.

💡 Commit your changes to git and push to git repo

Exercise: Lets add French language support

Solution: RED

/// old code


    t.Run("greeting in French", func(t *testing.T) {
        got := Hello("John", "fr")
        expected := "Bonjour, John"

        assert(t, expected, got)
    })

Run the test you should see hello_test.go:31: Expected "Bonjour, John" but got "Hello, John"

GREEN

const (
    englishHelloPrefix = "Hello, "
    spanishHelloPrefix = "Hola, "
    frenchHelloPrefix  = "Bonjour, "
)

const (
    spanish = "es"
    french  = "fr"
)

func Hello(name, lang string) string {
    if name == "" {
        name = "world"
    }

    if lang == spanish {
        return spanishHelloPrefix + name
    }

    if lang == french {
        return frenchHelloPrefix + name
    }

    return englishHelloPrefix + name
}

Now run the test, it should pass again.

REFACTOR

Now lets use switch statement to replace our if statements

const (
    englishHelloPrefix = "Hello, "
    spanishHelloPrefix = "Hola, "
    frenchHelloPrefix  = "Bonjour, "
)

const (
    spanish = "es"
    french  = "fr"
)

func Hello(name, lang string) string {
    if name == "" {
        name = "world"
    }

    prefix := englishHelloPrefix

    switch lang {
    case spanish:
        prefix = spanishHelloPrefix
    case french:
        prefix = frenchHelloPrefix
    }

    return prefix + name
}

And the test should still pass.

What we practiced here?

• Write a test first and see it fail (RED)

• Make the code and make compiler happy

• Run the test case and see it pass (GREEN)

• Commit your code to git at this point, so that further Refactor becomes seemless

• Refactor.

• Commit your code to git and push your changes to git repository.

Hope you enjoyed this TDD approach.

• Create a new folder called hello-world

• Create a new file in it called hello.go

mkdir hello-world
cd hello-world
touch hello.go

• Now write following code in it

package main

import "fmt"

func main() {
    fmt.Println("Hello, world!")
}

Run the program with following shell script go run hello.go .

Writing your first test

Go comes with built in test setup, this is a big deal if you are coming from other programming language where you need to setup your test, choose from different testing frameworks.

But how do we test the above code? Before writing a test case it is a good practice to separate your domain logic from the outside world (side effects). So lets do that first.

// main.go

package main

import "fmt"

func Hello() string {
    return "Hello, world!"
}

func main() {
    fmt.Println(Hello())
}

func keyword is used to create a function in Go. we named our function Hello() and we said this function should return string. Because Go is strongly typed language, this will helps us catch errors in compile time and our editor will help us fix them before even executing the program.

Lets create another file called hello_test.go and start writing our first test for our Hello function.

package main

import "testing"

func TestHello(t *testing.T) {
    got := Hello()
    expected := "Hello, world!"

    if got != expected {
        t.Errorf("expected %q got %q", expected, got)
    }
}

Few conventions in writing tests

• Test file name should xxx_test.go in our case hello_test.go

• The test function must start with the word Test in our case TestHello

• The test function takes one argument only t *testing.T

• In order to use the *testing.T type, you need to import import "testing".

Please note that, In the Go Installation and IDE Setup section, you'll find detailed setup instructions for both Visual Studio Code and Neovim. Once your IDE is configured correctly, it can efficiently handle the automatic import of necessary modules, simplifying your development process.

Go modules

Now that our test is ready you can run your test by typing go test in your terminal

$ go test
go: go.mod file not found in current directory or any parent directory; see 'go help modules'

If you see go.mod related problem, that means you are running go 1.16 or later, Go has a new module changes, you can read more about it Go Modules.

All you need to type is go mod init hello in your terminal followed by go mod tidy to fix this problem, and it will generate a go.mod file in your project.

$ go mod init hello      
go: creating new go.mod: module hello
go: to add module requirements and sums:
        go mod tidy
$ go mod tidy

If you are interested in what is generated in go.mod here is the content:

module hello

go 1.21.5

Now run go test command again and you will see your test is passing

$ go test    
PASS
ok      hello   0.001s

Next we will try to follow TDD approach to improve this hello world program.

To learn the basics of go language you don't need to Install Go in your computer, you can start with Go Playground - https://go.dev/play/.

Install Go

If you prefer to install go programming language in our computer click the link https://go.dev/doc/install, download and install go for your preferred OS.

Editor of your choice

• Visual Studio Code with Go Extension

• Neovim with lazyvim setup, here is how you can enable Go extras from lazyvim. If you want to learn more about this setup visit https://www.lazyvim.org/extras/lang/go

  • Open nvim and type :LazyExtras

    • 

      Go to Disabled section and find lang.go language, e.g /lang.go

• Press x from your keyboard to enable the go language plugin

And you are all set, now you are ready to write your go programs.

Here is the implementation we have done with Ruby on Rails. One small note, they already have https://github.com/mindee/mindee-api-ruby SDK for ruby on rails, but because our ruby version was not supported by SDK, I had to write a wrapper for it.

Here is a Ruby class I created for Mindee Document-based prediction API.

InvoiceFields is a Concern that extracts different required fields from Mindee's response.

# app/services/integrations/mindee/invoice_fields.rb

module Integrations
  module Mindee
    module InvoiceFields
      extend ActiveSupport::Concern

      def date
        value_of(:date)
      end

      def due_date
        value_of(:due_date)
      end

      def invoice_number
        value_of(:invoice_number)
      end

      def supplier_name
        value_of(:supplier_name)
      end
    end
  end
end

ConfidenceScore is another concern that returns the Average confidence score from line items.

# app/services/integrations/mindee/confidence_score.rb

module Integrations
  module Mindee
    module ConfidenceScore
      extend ActiveSupport::Concern

      # Confidence score of the average of the confidence scores of the line items
      def confidence_score
        return 0 if line_items.count.zero?

        sum_confidence = line_items.map { |item| item[:confidence] }.sum
        sum_confidence / line_items.length
      rescue StandardError => e
        puts "Error calculating confidence score: #{e.message}"
        0
      end
    end
  end
end

We are using HTTParty to make API calls, and here is the Mindee client wrapper.

# app/services/integrations/mindee/client.rb

module Integrations
  module Mindee
    class Client
      include HTTParty
      base_uri 'https://api.mindee.net/v1'
    end
  end
end

And finally, here is the predict_document.rb service class that makes an actual call to the API service.

# app/services/integrations/mindee/predict_document.rb

module Integrations
  module Mindee
    class PredictDocument
      # concerns
      include Integrations::Mindee::InvoiceFields
      include Integrations::Mindee::ConfidenceScore

      # attributes
      attr_reader :file, :error, :success, :response

      def initialize(file:)
        @file = file
        @error = nil
        @success = nil
        @token = ENV.fetch('MINDEE_API_KEY')
      end

      # Extract the invoice data from the file using the Mindee API
      def call
        return unless file.present?

        response = client.post(
          '/products/mindee/financial_document/v1/predict',
          body: { document: file },
          headers: {
            Authorization: "Token #{@token}"
          }
        )
        body = JSON.parse(response.body).with_indifferent_access

        @error =  !response.success?
        @success = response.success?
        @response = body
      end

      def line_items
        prediction[:line_items] || []
      end

      private

      def client
        @client ||= Integrations::Mindee::Client
      end

      def prediction
        @response.dig(:document, :inference, :prediction) || {}
      end

      def value_of(key)
        pred = prediction[key]

        if pred&.is_a?(Array)
          pred.first[:value]
        elsif pred&.is_a?(Hash)
          pred[:value]
        end
      end
    end
  end
end

How to Test the given service class using Mocha?

# Gemfile

group :test do
  gem 'mocha'
end

Generally, I like to make one valid API call to the service and put the actual response in the JSON file inside the test fixture, so that we can re-use that JSON in different test cases.

NOTE: Below JSON file does not contains valid JSON response

# test/fixtures/mindee_response.json

{
  "api_request": {
    ... 
  },
  "document": {
    "inference": {
      "extras": {},
      "finished_at": "2023-07-04T09:56:03.893829",
      "is_rotation_applied": true,
      "pages": [
        {
         ...   
        "line_items": [
          {
            "confidence": 0.99,
            "description": "test",
            "page_id": 0,
            "polygon": [],
            "product_code": "1",
            "quantity": 1.0,
            "tax_amount": null,
            "tax_rate": 0.0,
            "total_amount": 12.0,
            "unit_price": 12.0
          }
        ],
        "locale": {
          "confidence": 0.71,
          "currency": "EUR",
          "language": "en"
        },
        "reference_numbers": [
          {
            "confidence": 1.0,
            "page_id": 0,
            "polygon": [],
            "value": "#2534212-2023-07-03"
          }
        ],
        ...
       "started_at": "2023-07-04T09:56:02.755287"
    },
    "n_pages": 1,
    "name": "test.pdf"
  }
}

And finally, here is the mini test example:

require 'test_helper'

module Integrations
  module Mindee
    class PredictDocumentTest < ActiveSupport::TestCase
      setup do
        @response = File.read('test/files/mindee_response.json')
        @subject = Integrations::Mindee::PredictDocument
      end

      test 'should return error if response is not success' do
        Integrations::Mindee::Client.stubs(:post).returns(
          OpenStruct.new(success?: false, body: { response: { api_request: { error: 'something went wrong' } } }.to_json)
        )
        service = @subject.new(file: 'file')
        service.call
        assert service.error
      end

      test 'should return success if response is success' do
        assert stub_and_call_service.success
      end

      test 'should return the confidence score' do
        assert_equal 0.99, stub_and_call_service.confidence_score
      end

      test 'should return the invoice date' do
        assert_equal '2023-07-03', stub_and_call_service.date
      end

      test 'should return invoice items' do
        items = stub_and_call_service.line_items
        assert_equal 1, items.size
        assert_equal 'test', items.first[:description]
        assert_equal 1, items.first[:quantity]
        assert_equal 0, items.first[:tax_rate]
        assert_equal 12, items.first[:unit_price]
        assert_equal 12, items.first[:total_amount]
      end

      ...
    end
  end
end

def stub_and_call_service
  Integrations::Mindee::Client
    .stubs(:post)
    .returns(OpenStruct.new(success?: true, body: @response))
  service = @subject.new(file: 'file')
  service.call
  service
end

We can use stubs method to stub the post action from HTTParty and return our custom success or failed response. Also note that, we are directly stubbing Integrations::Mindee::Client service class and not the Integrations::Mindee::PredictDocument. That way when we call .call method it will stub the response and still allow us to test rest of the logic from the .call method, and that means, we can test both success and failure response logic.

Return Error response.

Integrations::Mindee::Client.stubs(:post).returns(
  OpenStruct.new(success?: false, body: { response: { api_request: { error: 'something went wrong' } } }.to_json)
)

Return Success response

Integrations::Mindee::Client.stubs(:post).returns(OpenStruct.new(success?: true, body: @response))
service = @subject.new(file: 'file')

Through this blog post, we have explored the key features of Mocha and demonstrated how it can be integrated with minitest to create robust test suites. We discussed the process of mocking and stubbing external APIs, enabling developers to isolate their code and test it in isolation from external factors. This approach not only enhances the reliability of tests but also accelerates development cycles by reducing the reliance on external services during the testing phase.

Follow https://github.com/tmux/tmux/wiki to install Tmux in your preferred OS.

Mac os users:

brew install tmux

Ubuntu users:

sudo apt update && sudo apt -y install tmux

Start using tmux

Create a new Tmux session and we will customize it.

tmux new -S <your session name>

# example:
tmux new -S tmux-conf

Create a Tmux configuration file

Create a tmux config file in your root directory ~/.tmux.conf and start adding the following scripts to customize the default Tmux UI and behaviors.

vim ~/.tmux.conf

# ~/.tmux.conf

unbind -r
bind r source-file ~/.tmux.conf

set -g prefix C-b

Here we are telling Tmux set r to reload the Tmux config and apply the changes to the current tmux session. And also we are setting C-b as a prefix key.

So if you do C-b + r your Tmux session should reload and new changes will get applied

Next we will set Vim keybindings to switch between panes

# act like vim
setw -g mode-keys vi
bind-key h select-pane -L
bind-key j select-pane -D
bind-key k select-pane -U
bind-key l select-pane -R

Install Tmux Plugin Manager

Next, lets install Tmux plugin manager https://github.com/tmux-plugins/tpm.

git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

Put this at the bottom of ~/.tmux.conf

# ...

# List of plugins
set -g @plugin 'tmux-plugins/tpm'
# Navigate tmux panes with `C-hjkl` just like vim.
set -g @plugin 'christoomey/vim-tmux-navigator'
set -g @plugin 'dracula/tmux'

set -g @dracula-show-powerline true
set -g @dracula-fixed-location "<Your city>"
set -g @dracula-show-fahrenheit false
set -g @dracula-plugins "weather"
set -g @dracula-show-flags true
set -g @dracula-show-left-icon session
set -g @dracula-show-empty-plugins false
set -g status-position top

# Initialize TMUX plugin manager (keep this line at the very bottom of tmux.conf)
run '~/.tmux/plugins/tpm/tpm'

Run C-b + I to install all the tmux plugins from your config file anytime you add new plugins

My complete .tmux.conf

###########################
#  Configuration
###########################

# use 256 term for pretty colors
# set -g default-terminal "screen-256color" # making tmux slow
set -g default-terminal "xterm-256color"

# Enable mouse support
set -g mouse on

# increase scroll-back history
set -g history-limit 5000

# use vim key bindings
setw -g mode-keys vi

# decrease command delay (increases vim responsiveness)
set -sg escape-time 1

# increase repeat time for repeatable commands
set -g repeat-time 1000

# start window index at 1
set -g base-index 1

# start pane index at 1
setw -g pane-base-index 1

# highlight window when it has new activity
setw -g monitor-activity on
set -g visual-activity on

# re-number windows when one is closed
set -g renumber-windows on

# Fix nightfly color scheme to display correctly inside tmux
set -ga terminal-overrides ',xterm-256color:Tc'

# enable pbcopy and pbpaste
# https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard/blob/master/README.md
# set-option -g default-command "reattach-to-user-namespace -l zsh"

###########################
#  Key Bindings
###########################

# tmux prefix
set -g prefix C-b

# paste
unbind C-p
bind C-p paste-buffer

# window splitting
unbind %
bind | split-window -h
unbind '"'
bind - split-window -v -p 20

# quickly switch panes
unbind ^B
bind ^B select-pane -t :.+

# switch panes using Alt-arrow without prefix
bind -n M-h select-pane -L
bind -n M-l select-pane -R
bind -n M-k select-pane -U
bind -n M-j select-pane -D

# swap windows
bind-key -n C-S-Left swap-window -t -1
bind-key -n C-S-Right swap-window -t +1

# Quickly view system & process info in htop
bind-key h split-window -h "htop"
# Quickly edit todo list
bind-key w split-window -h "vim ~/vimwiki/index.md"

# rails specific
bind-key -n M-s split-window -h "bundle exec sidekiq"
bind-key -n M-r split-window -v -p 20 "redis-server"

# force a reload of the config file
unbind r
bind r source-file ~/.tmux.conf \; display "Reloaded!"

###########################
# Status Bar
###########################

# set refresh interval for status bar
set -g status-interval 30

# center the status bar
set -g status-justify left

# show session, window, pane in left status bar
set -g status-left-length 40
set -g status-left '#[fg=green]#S#[fg=blue] #I:#P #[default]'

# show hostname, date, time, and battery in right status bar
set-option -g status-right '#[fg=green]#H#[default] %m/%d/%y %I:%M #[fg=red]#(battery discharging)#[default]#(battery charging)#{net_speed}'

###########################
# Colors
###########################

# color status bar
set -g status-style bg=colour235
set -g status-style fg=white

# highlight current window
set-window-option -g window-status-current-style bg=black
set-window-option -g window-status-current-style fg=green

# set color of active pane
set -g pane-border-style bg=colour235
set -g pane-border-style fg=black
set -g pane-active-border-style bg=green
set -g pane-active-border-style fg=black

# Resize pane
bind-key J resize-pane -D 5
bind-key K resize-pane -U 5
bind-key H resize-pane -L 5
bind-key L resize-pane -R 5

###########################
# Plugins
###########################
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'christoomey/vim-tmux-navigator'

# Display internet download and upload speed

# Initialize TMUX plugin manager (keep this line at the very bottom of tmux.conf)
run -b '~/.tmux/plugins/tpm/tpm'

class OrdersController < ApplicationController
  def approve
    order = Order.find params[:id]
    order.approve!

    redirect_to :back
  end
end

This action will approve the order and redirect the user to the previous location where he performed this action from. However, if this action was performed and the HTTP_REFERER is missing, which can lead to ActionController::RedirectBackError exception to be raised.

Rescue the exception

One way to solve this method is to rescue the Exception and redirect to the default location.

class OrdersController < ApplicationController
  rescue_from ActionController::RedirectBackError, with: :redirect_to_default


  def approve
    order = Order.find params[:id]
    order.approve!

    redirect_to :back
  end

  private

  def redirect_to_default
    redirect_to orders_path
  end
end

Using redirect_back

After Rails 5.x, we can use redirect_back it accept fallback_location as an argument where we can provide the fallback location if the HTTP_REFERER is empty.

class OrdersController < ApplicationController
  def approve
    order = Order.find params[:id]
    order.approve!

    redirect_back fallback_location: orders_path
  end
end

Old way

def role(params: {})
    params[:role].present? ? params[:role] : 'guest'
end

Using ActiveSupport#presence

def role(params: {})
    params[:role].presence || 'guest'
end

It makes our code clean. ActiveSupport#presence returns an object if it’s #present? otherwise returns nil. object.presence is equivalent to object.present? ? object : nil

Another example:

def address(params: {})
  params[:state].presence ||
    params[:city].presence ||
    params[:country].presence ||
    'US'
end

Happy coding 🤘

I love Tmux because using Tmux + Neovim makes a great IDE.

Depending on which Terminal app you are using, some things in Linux if you copy content from within the Tmux session, you can't paste them outside of Tmux, which can be a big pain most of the time.

To solve that problem we are going to install Xclip, it is a command line utility that is designed to run on any system with an X11 implementation and it allows you to use clipboard from your command line.

Install Xclip

sudo apt install xclip

Configure Tmux to use Xclip

Put following script in your tmux configuration file vim ~/.tmux.conf

#for copying to sys clipboard
bind -T copy-mode-vi Enter send-keys -X copy-pipe-and-cancel "xclip -i -f -selection primary | xclip -i -selection clipboard"
bind -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "xclip -i -f -selection primary | xclip -i -selection clipboard"
bind -T copy-mode-vi C-j send-keys -X copy-pipe-and-cancel "xclip -i -f -selection primary | xclip -i -selection clipboard"

Reload your tmux session usually prefix + r . And your clipboard from tmux session should work again.

This article will explain how to implement Feature Flags in Ruby on Rails using Flipper gem. It will cover different use cases for feature flags, as well as best practices for managing and testing them.

Setting up flipper

If you don't have a Rails app, you can generate one quickly using rails new my_app. Now open the Gemfile and add the following line to the setup:

gem "flipper-cloud"
gem "flipper-active_record"

Run bundle to install them

bundle install

If you're using the ActiveRecord adapter, you'll also need to generate the migrations and run them.

bin/rails g flipper:active_record
bin/rails db:migrate

This will generate a migration file that includes the required database table so that Flipper can work.

How to use Flipper in your project

After the setup is completed you can now use Flipper as a feature flag for your features. Some of the examples of features we have used Flipper with are:

• Sync Invoices To QuickBooks: We used Flipper to enable our Invoice sync with QuickBooks invoices as a beta feature for our certain beta customers. This way other customers who don't want to sync invoices will still use the app.

• Multiple Version of Dashboards for A/B testing: Flipper also has a great way to enable certain feature flags to a certain percentage of users.

• Feature Flags for Custom Reporting: Some customer wants their reports in a specific format and those reports should be only accessible to them.

• Continuous Deployment of new big feature: If your company follows a continuous deployment and DORA metrics, feature flags are very important to do risk-free continuous delivery of your app without breaking them in production. And you can allow your QA team or stakeholders to test them before even your full feature is completed.

These are mostly our use cases but they can differ based on how your team delivers the product to the end users.

Flipper makes it dead simple to enable/disable features for your app, for example:

class InvoiceSyncFeature
    def run
        return unless Flipper.enabled?(:qb_sync, current_user)

        sync_with_quickbooks
    end
end

How to enable the Flipper feature flags?

You can enable Flipper feature flags for different actors, most of the rails applications will have user as an actor.

Here is how you can enable it:

# Enable a feature for everyone
Flipper.enable :qb_sync

# Enable a feature for a specific actor
Flipper.enable_actor :qb_sync, current_user

# Enable a feature for a group of actors
Flipper.enable_group :qb_sync, :admin

# Enable a feature for a percentage of actors
Flipper.enable_percentage_of_actors :qb_sync, 2

Flipper UI

If you want to manage your feature flags from UI you can use:

gem 'flipper-ui'

Install it with bundle install

And mount it into your config/routes.rb file

YourRailsApp::Application.routes.draw do
  mount Flipper::UI.app(Flipper) => '/flipper'
end

Securing your flipper routes

Obviously, we don't want to leave the flipper open for everyone and mess around with it. For that, we are using the Devise gem and we only allow admins to access it. In our case, admins are our site owners.

authenticated do
    mount Flipper::UI.app(Flipper) => '/flipper', constraints: lambda { |req|
      current_user = req.env['warden'].user
      current_user.present? && current_user.admin?
    }
end

Or you can use basic HTTP authentication via Rack

# config/routes.rb

flipper_app = Flipper::UI.app do |builder|
  builder.use Rack::Auth::Basic do |username, password|
    # Verify credentials
  end
end
mount flipper_app, at: '/flipper'

Happy Hacking ;)