| # Enables PostgreSQL interval datatype support (as ActiveSupport::Duration) in Ruby on Rails 4.1. | |
| # Based on https://gist.github.com/clarkdave/6529610 | |
| require 'active_support/duration' | |
| # add a native DB type of :interval | |
| ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::NATIVE_DATABASE_TYPES[:interval] = { name: 'interval' } | |
| # add the interval type to the simplified_type list. because this method is a case statement | |
| # we can't inject anything into it, so we create an alias around it so calls to it will call |
This list is based on aliases_spec.rb.
You can see also Module: RSpec::Matchers API.
| matcher | aliased to | description |
|---|---|---|
| a_truthy_value | be_truthy | a truthy value |
| a_falsey_value | be_falsey | a falsey value |
| be_falsy | be_falsey | be falsy |
| a_falsy_value | be_falsey | a falsy value |
| require 'rubygems' | |
| require 'faraday' | |
| require 'socksify' | |
| require 'socksify/http' | |
| require 'awesome_print' | |
| # This is a SOCKS monkey patch for Faraday, with example use/unit test. | |
| # Notes: | |
| # * It is altered to work with SOCKS5 authentication. | |
| # * net_http_class must return a Faraday::Adapter::NetHttp instance. |
Note: This guide works with Ruby 2.6+ through Ruby 3.x, with modern Ruby 3.x features highlighted where applicable. Core metaprogramming concepts remain consistent across Ruby versions.
This document has been collaboratively updated and modernized through an interactive process with Claude Code, revised with examples, visual diagrams, and Ruby 3.x compatibility.
| # .railsrc | |
| -B #Skip Bundle | |
| -T #Skip Test-Unit | |
| -d postgresql #Use postgres |
| # .railsrc | |
| -B #Skip Bundle | |
| -T #Skip Test-Unit | |
| -d postgresql #Use postgres | |
| # template.rb | |
| #add guard-minitest and spring to dev | |
| gem_group :development do |
For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx.
Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon with HyperThreading enabled, but it can work without problem on slower machines.
You must understand that this config is used in testing environment and not in production so you will need to find a way to implement most of those features best possible for your servers.
| # Change YOUR_TOKEN to your prerender token | |
| # Change example.com (server_name) to your website url | |
| # Change /path/to/your/root to the correct value | |
| server { | |
| listen 80; | |
| server_name example.com; | |
| root /path/to/your/root; | |
| index index.html; |
| # | |
| # CORS header support | |
| # | |
| # One way to use this is by placing it into a file called "cors_support" | |
| # under your Nginx configuration directory and placing the following | |
| # statement inside your **location** block(s): | |
| # | |
| # include cors_support; | |
| # | |
| # As of Nginx 1.7.5, add_header supports an "always" parameter which |
| ; /usr/local/bin/nasm -f macho 32.asm && ld -macosx_version_min 10.7.0 -o 32 32.o && ./32 | |
| global start | |
| section .text | |
| start: | |
| push dword msg.len | |
| push dword msg | |
| push dword 1 | |
| mov eax, 4 |