One way to do this is to use bundler to scaffold our gem:
bundler gem my_gem
I prefer to put tasks meant to manage the gem itself in lib/tasks
, and tasks the gem is meant to provide to gem users in lib/my_gem/tasks
.
One way to do this is to use bundler to scaffold our gem:
bundler gem my_gem
I prefer to put tasks meant to manage the gem itself in lib/tasks
, and tasks the gem is meant to provide to gem users in lib/my_gem/tasks
.
(the video is here, the original talk notes are here)
At least one of those four patterns are in play when you talk about "event-driven" architectures:
v4l2-ctl --set-ctrl=zoom_absolute=130
require "bundler/inline" | |
gemfile do | |
gem "pundit", "2.1.0" | |
gem "graphql", "1.12.5" | |
source "https://gems.graphql.pro" do | |
gem "graphql-pro", "1.17.6" | |
end | |
end |
<!DOCTYPE html> | |
<html> | |
<body> | |
<h1>Before</h1> | |
<script> | |
// Object.assign | |
if (typeof Object.assign != 'function') { | |
Object.assign = function(target) { | |
'use strict'; |
# frozen_string_literal: true | |
require "bundler/inline" | |
gemfile(true) do | |
source "https://rubygems.org" | |
git_source(:github) { |repo| "https://github.com/#{repo}.git" } | |
# Activate the gem you are reporting the issue against. |
function listFolders(folder) { | |
var sheet = SpreadsheetApp.getActiveSheet(); | |
sheet.appendRow(["Name", "Sharing Access", "Sharing Permission", "Get Editors", "Get Viewers", "Date", "Size", "URL", "Download", "Description", "Type"]); //writes the headers | |
var folder = DriveApp.getFolderById("YOUR_FOLDER_ID");//that long chunk of random numbers/letters in the URL when you navigate to the folder | |
var files = folder.getFiles();//initial loop on loose files w/in the folder | |
var cnt = 0; | |
var file; |
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t
map <silent> <Leader>rl :w<cr>:silent call RunCurrentLineInTest('!ts bundle exec rspec')<cr>:silent redraw!<cr> | |
map <silent> <Leader>rt :w<cr>:silent call RunCurrentTest('!ts bundle exec rspec')<cr>:silent redraw!<cr> | |
" Test runner helpers | |
function! RunCurrentTest(rspec_type) | |
let in_test_file = match(expand("%"), '\(.feature\|_spec.rb\|_test.rb\)$') != -1 | |
if in_test_file | |
call SetTestFile() | |
if match(expand('%'), '\.feature$') != -1 |
#include <stdio.h> | |
#include <string.h> | |
#define OK 0 | |
#define NO_INPUT 1 | |
#define TOO_LONG 2 | |
#define SMALL_BUFF 3 | |
// https://stackoverflow.com/questions/2430303/disadvantages-of-scanf | |
static int getLine (char *prmpt, char *buff, size_t sz) { |