Omniref's blog covers Ruby performance and internals, plus the company's code documentation search site for Ruby gems.
HN commenters tried its Ruby docs search and found it useful for symbols and operators, while noting gaps like missing gems and inherited options.
The article isn't particularly well written or argued, but it does have a core of truth to it: serious code review in GitHub is painful. However jumping straight to Gerrit to solve that problem seems like overkill to me. Sure, you get a really powerful and extremely configurable code review system, but you have to retrain for a new (and honestly a little long in the tooth) UX and spend time administrating the system.
A lighter-weight SaaS like https://review.ninja, https://omniref.com, or https://reviewable.io (disclosure: this one's mine) might be a more appropriate solution. Specifically to the article's points, Reviewable has a nice reviews dashboard and will show inter-commit diffs within a PR (whether you're rebasing/amending or not), hiding any files with no changes since you last looked. Its default review completion criterion is that all files have been marked as reviewed by at least one person and there are no unresolved discussions still going on, but you can customize this to your team by writing a snippet of code to run against the review's state, e.g. to implement LGTM approval or even a voting system. Reviewable will also update a status check on the PR so you can enforce review completion before merging if that works best for your situation.
Best of all, because both systems integrate tightly with GitHub, there's no need to learn a new workflow or mess around with new git commands. Gerrit still has its place but I don't think it should be the tool of…
That was a neat investigation and use of omniref.
I just posted a question: https://www.omniref.com/ruby/gems/activerecord/4.2.0/symbols/ActiveRecord::Persistence/delete?#annotation=4079388
I see that it popped up under recent questions on the home page. Once a question gets bumped off that list, is there an easy way to find it (e.g. through search) or can one only find it if they happen to be viewing the Q&A tab under the same file?
Since this is my first question there, I'm not sure if I have to check back repeatedly for answers or if I'll get notified somehow.
Well inlining this way is an optimisation which the compiler may or may not opt to apply, even after adding inlining hints. By manually inlining it they're introducing a little bit of trivial redundancy but I guess they can be certain there will be no indirect call.
Either that, or they never considered the compiler would most likely inline it.
Oddly enough, they do it for string comparisons: https://www.omniref.com/ruby/2.1.4/files/vm_insnhelper.c#line=860
Actually, that's already happening[1]. Also note that there is a library for "ruby contracts[2]" (which I didn't try yet, but I'm very eager to do so) which could give the same result as a statically typed language.
[1] https://www.omniref.com/blog/blog/2014/11/17/matz-at-rubyconf-2014-will-ruby-3-dot-0-be-statically-typed/
[2] http://egonschiele.github.io/contracts.ruby/.
Enumerate options that are obscured by inheritance. For example, to look at:
http://www.omniref.com/?q=cache_action
I don't know what options are valid in `cache_action`. The "real" answer, AFAICT, is to keep walking up the source code until you find the AbstractWhatever that actually defines the options.
Very nice. symbol hound just isn't that great so it's good that at least rubydocs can be searched properly for that spaceship and stuff. aw, can't find the stabby lambda, but at least you've got a nice 404 page :) http://www.omniref.com/?q=-%3E