(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| app.directive('faFastScroll', ['$parse', function ($parse) { | |
| var Interval = function(min, max) { | |
| this.min = min || 0; | |
| this.max = max || 0; | |
| }; | |
| Interval.prototype.clip = function(min, max) { | |
| if(this.max <= min || this.min >= max) { | |
| this.min = this.max = 0; |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| ###################### | |
| # | |
| # Monkey patch to ActiveRecord to prevent 'implicit' checkouts. Currently tested with Rails 4.0.8, prob | |
| # should work fine in Rails 4.1 too. | |
| # | |
| # If you create a thread yourself, if it uses ActiveRecord objects without | |
| # explicitly checking out a connection, one will still be checked out implicitly. | |
| # If it is never checked back in with `ActiveRecord::Base.clear_active_connections!`, | |
| # then it will be leaked. | |
| # |
| CREATE INDEX index_description_on_icd_codes ON icd_codes USING gin(to_tsvector(description)) |
My largest Sidekiq application had a memory leak and I was able to find and fix it in just few hours spent on analyzing Ruby's heap. In this post I'll show my profiling setup.
As you might know Ruby 2.1 introduced a few great changes to ObjectSpace, so now it's much easier to find a line of code that is allocating too many objects. Here is great post explaining how it's working.
I was too lazy to set up some seeding and run it locally, so I checked that test suite passes when profiling is enabled and pushed debugging to production. Production environment also suited me better since my jobs data can't be fully random generated.
So, in order to profile your worker, add this to your Sidekiq configuration:
if ENV["PROFILE"]| /* bling.js */ | |
| window.$ = document.querySelector.bind(document); | |
| window.$$ = document.querySelectorAll.bind(document); | |
| Node.prototype.on = window.on = function(name, fn) { this.addEventListener(name, fn); }; | |
| NodeList.prototype.__proto__ = Array.prototype; | |
| NodeList.prototype.on = function(name, fn) { this.forEach((elem) => elem.on(name, fn)); }; |
I've taken the benchmarks from Matthew Rothenberg's phoenix-showdown, updated Phoenix to 0.13.1 and ran the tests on the most powerful machines available at Rackspace.
| Framework | Throughput (req/s) | Latency (ms) | Consistency (σ ms) |
|---|
| defprotocol Blank do | |
| @doc "Returns true if data is considered blank/empty" | |
| @fallback_to_any true | |
| def blank?(data) | |
| end | |
| defimpl Blank, for: Any do | |
| def blank?(_), do: false | |
| end |
See also, http://libraryofalexandria.io/cgo/
cgo has a lot of trap.
but Not "C" pkg also directory in $GOROOT/src. IDE's(vim) Goto command not works.
So, Here collect materials.