rails new blog
cd blog
hanami new bookshelf
vim Gemfile # add `hanami`
bundle
vim bookshelf/config/environment.rb # See Note 1
#include <Wire.h> | |
#include <Adafruit_GFX.h> | |
#include <Adafruit_IS31FL3731.h> | |
Adafruit_IS31FL3731_Wing ledmatrix = Adafruit_IS31FL3731_Wing(); | |
void setup() { | |
Serial.begin(9600); | |
if (!ledmatrix.begin()) { | |
Serial.println("IS31 not found"); |
FROM ruby:2.4.1 | |
RUN apt-get update -qq && apt-get install -y build-essential | |
# for postgres | |
RUN apt-get install -y libpq-dev | |
# for nokogiri | |
RUN apt-get install -y libxml2-dev libxslt1-dev |
// license: BSD3 | |
const WEBMERCATOR_R = 6378137.0; | |
const DIAMETER = WEBMERCATOR_R * 2 * Math.PI; | |
class Mercator { | |
static project(lon, lat) { | |
var x = DIAMETER * lon/360.0; | |
var sinlat = Math.sin(lat * Math.PI/180.0); | |
var y = DIAMETER *Math.log((1+sinlat)/(1-sinlat)) / (4*Math.PI); | |
return { x, y }; | |
} |
http://stackoverflow.com/questions/22667401/postgres-json-data-type-rails-query | |
http://stackoverflow.com/questions/40702813/query-on-postgres-json-array-field-in-rails | |
#payload: [{"kind"=>"person"}] | |
Segment.where("payload @> ?", [{kind: "person"}].to_json) | |
#data: {"interest"=>["music", "movies", "programming"]} | |
Segment.where("data @> ?", {"interest": ["music", "movies", "programming"]}.to_json) | |
Segment.where("data #>> '{interest, 1}' = 'movies' ") | |
Segment.where("jsonb_array_length(data->'interest') > 1") |
I have been carrying this Rakefile around between projects, that uses another file which reopens the FlogTask
class and adds an attr_accessor
to it, which the task definition in the Rakefile then uses.
This works but, as you can readily tell, it's less than ideal. In particular, the Rakefile
defines multiple tasks which are the same for each project; the only change is usually the Flog threshold value.
What I want to be able to do is:
- Subclass a tool's standard Rake task (e.g.,
FlogTask
). The subclass'#initialize
method would then set up our standard settings as is presently done in the Rakefile; - Define namespaced Rake tasks (in, e.g.,
lib/tasks/custom_flog.rake
) that use those subclasses rather than the tool's standard Rake task; reducing boilerplate and possibility of copy/paste errors; - Have those tasks be available in
Optimistic Locking assumes that a database transaction conflict is very rare to happen. It uses a version number of the record to track the changes. It raise an error when other user tries to update the record while it is lock.
usage
Just add a lock_version column to the table you want to place the lock and Rails will automatically check this column before updating the record.
Pessimistic locking assumes that database transaction conflict is very likely to happen. It locks the record until the transaction is done. If the record is currently lock and the other user make a transaction, that second transaction will wait until the lock in first transaction is release.
usage