sesharim

/*
********************************************************************************
Golang - Asterisk and Ampersand Cheatsheet
********************************************************************************

Also available at: https://play.golang.org/p/lNpnS9j1ma

Allowed:
--------
p := Person{"Steve", 28} 	stores the value

sesharim

require 'cgi'
require 'active_support'

def verify_and_decrypt_session_cookie(cookie, secret_key_base = Rails.application.secret_key_base)
  cookie = CGI::unescape(cookie)
  salt   = 'authenticated encrypted cookie'
  encrypted_cookie_cipher = 'aes-256-gcm'
  serializer = ActiveSupport::MessageEncryptor::NullSerializer

  key_generator = ActiveSupport::KeyGenerator.new(secret_key_base, iterations: 1000)

sesharim

A Primer on Ruby Method Lookup

Method lookup is a simple affair in most languages without multiple inheritance. You start from the receiver and move up the ancestors chain until you locate the method. Because Ruby allows you to mix in modules and extend singleton classes at runtime, this is an entirely different affair.

I will not build contrived code to exemplify the more complicated aspects of Ruby method lookup, as this will only serve to confuse the matter. If you are having trouble following method lookup in your own programs, it is not because Ruby has strange rules (it does), it is because your code is too tangled.

When you pass a message to an object, here is how Ruby finds what method to call:

1. Look within singleton class

sesharim

class LinkedList
	class Node
		attr_accessor :next, :data
		def initialize data
			self.data = data
			self.next = nil
		end
	end

	attr_accessor :head, :tail, :length

sesharim

module Storage
  module Models
    class Brand < ActiveRecord::Base; end
  end
end

sesharim

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules

sesharim

require 'dry-validation'

class NewUserContract < Dry::Validation::Contract
  params do
    required(:email).filled(:string)
    required(:age).value(:integer)
  end

  rule(:email) do
    key.failure('oi mate') if false

sesharim

class MyJob < ActiveJob::Base
  queue_as :urgent

  rescue_from(NoResultsError) do
    retry_job wait: 5.minutes, queue: :default
  end

  def perform(*args)
    MyService.call(*args)
  end

sesharim

```
scope :arel, ->(column, predication, *args) { where(arel_table[column].public_send(predication, *args)) }
```

Example usage of the scope:

```
MyModel.arel(:created_at, :lt, 2.days.ago)
```
For all predications, check the documentation or source code.

sesharim

Originally published in June 2008

When hiring Ruby on Rails programmers, knowing the right questions to ask during an interview was a real challenge for me at first. In 30 minutes or less, it's difficult to get a solid read on a candidate's skill set without looking at code they've previously written. And in the corporate/enterprise world, I often don't have access to their previous work.

To ensure we hired competent ruby developers at my last job, I created a list of 15 ruby questions -- a ruby measuring stick if you will -- to select the cream of the crop that walked through our doors.

What to expect

Candidates will typically give you a range of responses based on their experience and personality. So it's up to you to decide the correctness of their answer.