dd-trace-rb
vim-projectionist
dd-trace-rb | vim-projectionist | |
---|---|---|
4 | 25 | |
290 | 1,033 | |
0.3% | - | |
10.0 | 4.6 | |
1 day ago | about 2 months ago | |
Ruby | Vim Script | |
GNU General Public License v3.0 or later | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dd-trace-rb
-
The end of "Useless Ruby sugar": On intuitions and evolutions
Thing is, once you have 1) and 2), the added complexity of bringing in, integrating, and writing for a different tool to achieve 3) begins to make little sense, when you can just go along and do it just as well in rspec anyway... It's a matter of balance and heavily depends on the project.
> if you're still at Datadog
As a matter of fact I am. Feel free to shoot me an email.
curl -s https://github.com/DataDog/dd-trace-rb/commit/176c642ca73679cabc5fa1a113bc9b600aa04dcd.patch | grep '^From:'
-
A few words on Ruby's type annotations state
> For myself, I'm fine with the typing being in a separate .rbs file
We type[0] by having one separate .rbs file per .rb file. Works really well with an editor's vertical splits: type outline on one side, code on the other. That, or use something like vim-projectionist[1].
[0]: (WIP: there's a huge codebase to type, but we're progressively getting there) https://github.com/DataDog/dd-trace-rb/tree/master/sig
[1]: https://github.com/tpope/vim-projectionist
-
Why Authorization Is Hard
Thanks! I'll pass it on to the team :D
I've got to say, the folks at Intercom made it particularly fun. They were sending us traces and graphs from their internal systems when we trying to figure out some issues with them (e.g. we ran into this datadog context problem: https://github.com/DataDog/dd-trace-rb/issues/1389)
vim-projectionist
-
What plugins do you use to manage work across multiple files?
Tim Pope's projectionist for navigating to files of a particular category or to related files from the current one: https://github.com/tpope/vim-projectionist.
-
A few words on Ruby's type annotations state
> For myself, I'm fine with the typing being in a separate .rbs file
We type[0] by having one separate .rbs file per .rb file. Works really well with an editor's vertical splits: type outline on one side, code on the other. That, or use something like vim-projectionist[1].
[0]: (WIP: there's a huge codebase to type, but we're progressively getting there) https://github.com/DataDog/dd-trace-rb/tree/master/sig
[1]: https://github.com/tpope/vim-projectionist
-
What's the coolest thing you've done with Neovim?
One of the originals I guess must be tim pope's https://github.com/tpope/vim-projectionist
- Could use some advice for managing projects in a way that fits my mental model and codebase. Monolithic codebase with project files spread around different working directories. Or just help me change my mental model.
-
Project & File navigation
use https://github.com/tpope/vim-projectionist - define the relationships between files (example: app/*js are 'source' files and test/*js are 'test' files). Projectionist sets up `:A` to jump to the 'alternate' file (jump between a 'source' file and its 'test' for instance), and `:Esource` and `:Etest` commands to find/navigate by the kind of file. This is very powerful IMO - for projects with good structure I can quickly jump between related test/source/model/blah files very quickly using these commands. For projects without good structure I rethink or get the team to talk about how we might improve the project organization (ie, lack of structure is a code smell!)
-
New Plugin: telescope-alternate
I love Tpope’s https://github.com/tpope/vim-projectionist but this one seems like a great replacement 😎
-
JVM language users- how do you write your test files?
Tim Pope's excellent Projectionist plug-in has an alternate file feature, which makes it very easy to switch between test and implementation files.
-
other.nvim - open alternative files for the current buffer.
The plugin is inspired by vim-projectionist and https://github.com/vim-scripts/a.vim
-
vim-projectionist isn't autoloading in Vim
This feels like a bug, since the plugin doesn't behave as expected when following the installation section verbatim. I filed a bug here: https://github.com/tpope/vim-projectionist/issues/168
-
Auto-open unit test file
You need https://github.com/tpope/vim-projectionist. Gotta have a file structure for unit tests though.
What are some alternatives?
cerbos - Cerbos is the open core, language-agnostic, scalable authorization solution that makes user permissions and authorization simple to implement and manage by writing context-aware access control policies for your application resources.
jumpwire.nvim - Jump easily between related files.
ffi - Ruby FFI
denite.nvim - :dragon: Dark powered asynchronous unite all interfaces for Neovim/Vim8
Ory Keto - Open Source (Go) implementation of "Zanzibar: Google's Consistent, Global Authorization System". Ships gRPC, REST APIs, newSQL, and an easy and granular permission language. Supports ACL, RBAC, and other access models.
autojump - A cd command that learns - easily navigate directories from the command line
casbin-server - Casbin as a Service (CaaS)
vim-rails - rails.vim: Ruby on Rails power tools
Rails Performance - Monitor performance of you Rails applications (self-hosted and free)
bufexplorer - BufExplorer Plugin for Vim
OPA (Open Policy Agent) - Open Policy Agent (OPA) is an open source, general-purpose policy engine.
fzf.vim - fzf :heart: vim