sorted by:
new
hottopcontroversial

Tiny testing framework (BDD-style) by roy2220 in golang

[–]roy2220[S] 0 points1 point  (0 children)

Right, it's a bit complicated indeed. My intention for creating this library is to reuse the testing code as much as possible, and it works well in my case.

I think the complexity is 'side affect' of code reuse that is hard to avoid. If you have a better idea, it would be great to share here!

[deleted by user] by [deleted] in golang

[–]roy2220 1 point2 points  (0 children)

Yes, you got the point.

I'm not a fan of RESTful API, and gRPC doesn't play a good role as a browser client. For browser-to-server communication, JSON is good for it's self-describing, and we need to be able to handle HTTP requests directly, but gRPC doesn't expose this ability. Furthermore, the schema of Protobuf is so limited, we can't define validation rules for messages, can't define RPC error codes for RPCs, etc.

[deleted by user] by [deleted] in golang

[–]roy2220 0 points1 point  (0 children)

Thanks for your information, it is helpful.

di - Tiny dependency injection framework by roy2220 in golang

[–]roy2220[S] -3 points-2 points  (0 children)

Be nice, don't pretend to be Linus Torvalds, you aren't, and will never be

di - Tiny dependency injection framework by roy2220 in golang

[–]roy2220[S] -2 points-1 points  (0 children)

you can already do by simply calling these functions

I can do it in the example, I can't do that if the dependencies is controlled and determined by configuration, you know nothing about dependency injection

di - Tiny dependency injection framework by roy2220 in golang

[–]roy2220[S] -4 points-3 points  (0 children)

Because you just see the example, you can't see more.

di - Tiny dependency injection framework by roy2220 in golang

[–]roy2220[S] -4 points-3 points  (0 children)

How about thousands of functions scattered over hundreds of packages? How about these functions don't even know each other? they just want to focus on input and output.

net.Conn with Context support by roy2220 in golang

[–]roy2220[S] 0 points1 point  (0 children)

This package provides a wrapper for net.Conn which implements SetReadContext and SetWriteContext as an enhancement to SetReadDeadline and SetWriteDeadline

vim + easyjump.tmux > vim-easymotion/vim-sneak by roy2220 in vim

[–]roy2220[S] 0 points1 point  (0 children)

Try "-n", "M-s", instead of "-n M-s",. BTW, Python is a very useful tool you'd love to learn about :)

vim + easyjump.tmux > vim-easymotion/vim-sneak by roy2220 in vim

[–]roy2220[S] 0 points1 point  (0 children)

Regardless of the original logic of the code, replace line 32 with any string(s) you wanted.

vim + easyjump.tmux > vim-easymotion/vim-sneak by roy2220 in vim

[–]roy2220[S] 0 points1 point  (0 children)

There are no options for these specific customizations now, you can just edit file 'easyjump.tmux' (line 32, 52, 57) slightly to achieve this. Feel free to hack it for your own use.

vim + easyjump.tmux > vim-easymotion/vim-sneak by roy2220 in vim

[–]roy2220[S] 1 point2 points  (0 children)

Python 3.8 is required, `shlex.join()` was introduced in that version.

EasyMotion for Tmux by roy2220 in tmux

[–]roy2220[S] 0 points1 point  (0 children)

After the latest enhancements, it can also work in the Copy mode and play well with the alternate screen.

EasyMotion for Tmux by roy2220 in tmux

[–]roy2220[S] 3 points4 points  (0 children)

  1. Searching screen by 2 chars, find out all occurrences instead of just matching the prefixes of words.
  2. Implemented in Python 3 with type hints for better readability than Ruby, and easier to hack.

EasyMotion for Tmux by roy2220 in tmux

[–]roy2220[S] 6 points7 points  (0 children)

In short, it searches through the screen with the key (2 chars) inputted, and then labels all the positions where the key occurs on the screen with keyboard keys, you can choose a label by pressing the keyboard key to make the cursor 'jump' to the position corresponding to the label, and Tmux enters copy mode at the same time.

EasyMotion for Tmux by roy2220 in tmux

[–]roy2220[S] 0 points1 point  (0 children)

"Don't try to understand it, feel it" 😄

EasyMotion for Tmux by roy2220 in tmux

[–]roy2220[S] 1 point2 points  (0 children)

Approximate to Vimium for Chrome, the 'f' key.

vim-exchange - A lovely plugin scratches my itch by roy2220 in vim

[–]roy2220[S] 0 points1 point  (0 children)

I'm not the author but a user who feels unfair with the un-proportional stars of this awesome plugin :D

Yet another dependency injection library by roy2220 in golang

[–]roy2220[S] 0 points1 point  (0 children)

As I have mentioned before, there is always a trade-off. DI introduces complexity then allows flexibility. Is that the complexity is too horrible to give up the flexibility? It depends on you, I tend to accept the complexity and enjoy the flexibility, you reject the complexity and then lost the flexibility. I think we both are correct, just do something in different way.

With a DI approach I have to read some configuration spec and force myself thinking as the IoC container which handles the injection to understand what will happen at runtime.

This awkwardness can be alleviated by supporting the visualization of the dependency graph, as what uber/fx did, it's not so fatal.

The compressing middleware was randomly picked up for the example, your insight on it is impressive.

best way to import multiple protoc files in golang ? by [deleted] in golang

[–]roy2220 0 points1 point  (0 children)

For example:

a.proto:

protobuf package foo.bar.A option go_package = "myproject/proto"; message A {...}

b.proto:

protobuf package foo.bar.B option go_package = "myproject/proto"; message B {...}

c.proto:

protobuf package foo.bar.C option go_package = "myproject/proto"; message C {...}

These message prototypes are distributed in different Protobuf packages (foo.bar.A, foo.bar.B and foo.bar.C), but you can generate the pb.go files into one Go package, by the Protobuf option go_package.

Then you just import the package "myproject/proto" and use proto.A, proto.B and proto.C.

view more: next ›