I need to reuse a function plug on different modules but it seems a bit redundant to do that. Is a module plug a better way to do this or how can I reuse the function plug?
A module plug is better for reusability purpose. It's best practice to always consider the scope of use of a plug before writing any plug.
To reuse the module plug, add it to a pipeline in router.ex file
Related
I'm trying to learn and use Fuchsia for fun, and a pretty basic concept is keeping me from progressing.
I thought that, as a learning experience, I could write a simple HTTP client that prints the content of some random URL to the log. Really nothing fancy.
As I understand, using the network (in my case I'd like to utilize fuchsia.net.http.Loader) is a capability, which has to be granted to a running component. Makes sense, that's pretty much the core of the OS.
I also understand that the initiating component, the one that runs my component, needs to grant this capability to my component. That's fair.
What I don't understand, and I'd very much appreciate any additional information (pretty please!) is how I can grant this to my component?
Specifically all demos and examples I saw had a custom client & server under a realm, which talked to each other. That's a good practice, but it doesn't bring in any capability that's built in.
What am I missing? Thanks in advance!
I'm trying to learn and use Fuchsia for fun, and a pretty basic concept is keeping me from progressing.
Thanks for your interest in Fuchsia! First of all, if you haven't already gone through Fuchsia Fundamentals I would strongly suggest that as a starting point for many of the foundational concepts.
Specifically all demos and examples I saw had a custom client & server under a realm, which talked to each other. That's a good practice, but it doesn't bring in any capability that's built in.
This is primarily because there's isn't necessarily a concept of any set of components or capabilities being "built in" to the system. The capabilities available to components in the system are entirely dependent on the rest of the components in a particular product build and how they are organized (this is called the component topology).
I thought that, as a learning experience, I could write a simple HTTP client that prints the content of some random URL to the log. Really nothing fancy.
The answer has a few sharp edges to it at the moment, as Fuchsia is a rapidly evolving open source project. Hopefully some of the details below will help you move forward.
Determine the capability routes
So you'll have to do a bit of work to figure out where the capability you need is provided and routed. In fact, one of the components exercises shows you how to do this for the fuchsia.net.http.Loader capability. Knowing where a capability is offered/used allows you to determine where your component would need to be instantiated to obtain the necessary capability.
You might also find some of the content in the Connect components developer guide useful in accessing the capability.
Run the component
Knowing where a capability is routed allows you to determine how to run your component. The most straightforward way of instantiating a component in the topology is to do so dynamically using ffx component. However, this requires a collection somewhere on the system with the capabilities you need. The ffx-laboratory realm where most examples are run has a very limited set of capabilities that does not include fuchsia.net.http.Loader.
You'll likely need to add your component statically to the topology using a core realm shard so that the necessary routes can be declared explicitly between the components that offer fuchsia.net.http.Loader and your component. With the component included statically in your product build, you can execute it using ffx component commands.
For more details on component execution, check out the Run components developer guide as well.
Run a CLI binary
Since this is a learning exercise, another option is to build your code as a binary that runs within the context of a component that already has the capabilities you need vs. creating and running an entirely new component. This is commonly used for CLI tools. With the ffx component explore command you can run your code as a binary inside the existing component that provides the HTTP capability you are looking for using the --tools argument, without the need to work through all the capability routing pieces described above.
For more details on ffx component explore, see Explore components.
I'm going to write a service that will using amqp protocol, without http at all. I like hanami's paradigm of repository-entity-model-interactors and I wonder to use those in my project. Generating all that stuff by hand, sure, is boring.
So, I wonder to grab rake tasks. Looking into config/environment etc, ughhhh. What is the best method, shortly, to use those tools without hanami router and controllers? Or, it is all integrated tightly?
As I think for that moment, there are two ways:
a) To include only hanami-model into my Gemfile, then copy by hand every needed file from gem hanami.
b) To create hanami project and do not use rackup.
I'm disappointed.
Alternatively, you can add hanami as a development gem. That gives you access to the code generators. At the deploy stage, you don't bundle hanami, so the app will only have hanami-model and hanami-utils in production.
hello. If I understand you right, you want to use interactors only with models. Interactors you can use as a regular ruby library.
For model, you need to configure all this staff and load to memory. You can check the example from our playbook. Hope it'll be helpful for you
https://github.com/hanami/playbook/blob/master/development/bug_templates/model_psql.rb
Is there a way how I can call golang functions from jsonnet?
Now that there is a go port of jsonnet and for example ksonnet is adding custom native functions I am wondering if there is a way how to extend jsonnet with more native functions?
I have many packages written in golang (with unit-testing, etc) and now it seems like I will need to rewrite some of them into jsonnet.
As discussed in the go-jsonnet's issue Custom builtin functions #223, you can introduce your custom golang functions but a pluggable support is not available - you cannot directly use the functions in a jsonnet binary.
You need to compile your own binary/library that creates an instance of vm.NativeFunction jsonnet VM and then add your native functions there.
I am writing a gem which adds dependencies to a gemfile from the command line. Given the gem name, it grabs the latest version from rubygems and adds it to the user's gemfile.
I practice test driven development using rspec. I'm wondering how do I mock the existence of a file and check it's contents?
Is there any pattern for doing this sort of thing? Tips, links or examples will help. I'm not set on a specific way of testing this. If mocking isn't the way to go, please let me know. Thanks!
If you want to mock a file object that only needs to be written and read from (no filesystem operations), try Ruby's builtin StringIO. Just require 'stringio', create a 'file' with any contents by using StringIO.new("Some contents"), and check its contents by using the string method on the StringIO object.
Unit Tests vs. Integration Tests
You didn't post any code, so I'm going to have to make some assumptions. In general, exercising behavior from Ruby's core or standard libraries is a waste of time. In addition, your tests should exercise methods that define class behavior, not necessarily every single method in a class.
When you cross the boundary to testing I/O, you're often doing integration tests. Sometimes integration tests are necessary, but they should make a very small subset when compared to unit tests.
With all that said, while integration tests that involve filesystem, database, or network I/O are often slower than unit tests, whether or not they are slow enough to warrant stubbing, mocking, or test-specific work-arounds will be specific to your code base.
Options for Testing
If you really need to do this, you have a lot of options. Some of these options include:
Using a RAM disk for your filesystem I/O.
Stubbing calls to IO, File, or FileUtils.
Avoiding the issue by using a file fixture.
Avoiding the issue by using a StringIO fixture.
Re-writing your class under test to accept String and/or StringIO in addition to File objects.
Using a gem like FakeFS to handle the stubbing/mocking for you.
This isn't meant to be an canonically exhaustive list. There are doubtless other options, but one or more of the above should handle any common use case.
I'm writing a simple measurement application which will be use bluetooth to talk to the device.
My question is where to put bluetooth connection initialization code? To Model or to Controller?
From my understanding of MVC, Model is what an application is - data models and all logic which applies to the data. And the Controller is some kind of glue between Model and View.
But for me it seems that it would be better to put connection code to the Controller since maybe in the futre there will be new version of the device which will use USB or something else.
What do you think what fits better in my case?
Best Regards,
Marcin
depends on the environment, but we follow the "thin controllers, thick models" principle. Having said that, a library of connection functions would fit in neither.
In the environment I work in, device connection functions would be best suited to a library (then you can have multiple libraries covering all connection types you may want to use in the future, as they are developed) which is then utilized in the appropriate place.
This would also allow re-use at a later stage in different projects/software if required.
A library would ideally have generic functions ( e.g. connectToDevice() and getFile() rather than getApplicationSpecificPhotosFromDevice ), with the app specific stuff happening in the controller and underlying model that uses the library to retrieve or submit data.