This isn't a problem but I don't really understand it and i'm feeling like i miss a important part in vulkan. My question is why is there a parameter for pLayerName in vkEnumerateInstanceExtensionProperties() function. Has this pLayerName anything to do with validation layers ? I've read the spec but it only told me that it would be a layer to retrieve extensions from. But for me this doesn't make sense because what does a validation layer(if this is meant for pLayerName) to do with extensions.
From the spec:
When pLayerName parameter is NULL, only extensions provided by the Vulkan implementation or by implicitly enabled layers are returned. When pLayerName is the name of a layer, the instance extensions provided by that layer are returned.
Layers can expose extensions; by specifying the name of a layer, you can query which extensions it exposes through this function. You can then create an instance using that layer with that extension.
Note that the term "validation layers" represents Vulkan layers which are used to validate usages of the Vulkan API. Not every layer exists to do validation. And some validation layers themselves expose instance extensions.
Related
I am using strongly typed ids in my domain model, mostly following the guidance from Andrew Lock at:
https://andrewlock.net/using-strongly-typed-entity-ids-to-avoid-primitive-obsession-part-1/
These ids, e.g. ProductId, CustomerId, etc. are declared in the Domain Model.
My question is about exposing these to consumers of the Application layer. At the moment, an API controller could create a Command to send to the Application layer. These commands also needs to use Ids. My current implementation in the Command objects is use the primitive type, Guid, and then create a Strongly Typed Id when calling methods on the Domain Model.
However, it makes sense to extend the control offered by using strongly typed ids to communication between the API Controller and the Application Layer. But, I do not want my API Controllers to have a reference to the Domain Model (which is where the Strongly Typed Ids are declared at the moment).
How to go about this?
Declare a similar set of Strongly Typed Ids from the Application Layer. But this would still need a translation between the Application declaration and the Domain Model declaration before calling methods in the Domain.
Move the declaration of Ids into a 'public' module that both the API and Domain Model can reference. But this would mean some leakage of Domain Model dependencies to the API Controller dependencies and any change in my Domain Model approach may impact the API Controllers, which is not desirable.
The ask seems reasonable, but neither of the above solutions feel optimal. Any thoughts?
Having reviewed Vaughn Vernon's book "Implementing Domain-Driven Design":
https://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/ref=asc_df_0321834577/
I have followed the advice on page 580, which is basically "be pragmatic".
Specifically,
For Ids and any other value object that I consider pretty 'fixed' I have chosen to use a shared kernel that API, Application and Domain layers can use (i.e. option 2 from my question).
For other, potentially more complex, value objects that may contain additional business logic specific to the Domain and may be more volatile in response to business change, then I am using option 1 from my question and creating a slimmed down (DTO) version for exposing from the Application and performing mapping from those to the Domain Model versions.
In TensorFlow (Python), when adding to the graph a tf.train.RMSPropOptimizer, are any additional variables added that need initialization? If yes, how can I get access to them and initialize them manually? (I'd rather not use tf.global_variables_initializer). In other words:
(1) How can I decide which initializer to use?
(2) How can I add the initilizer op to the graph, specifically for these variables?
EDIT 1:
I'm referring here to any new tf.Variable that is added to the graph whenever I add the RMSPropOptimizer, and how it is initialized (just like other tf.Variables). I'm not referring to the arguments in constructor of the RMSPropOptimizer, (which are hyper parameters of the model).
In TensorFlow (Python), when adding to the graph a tf.train.RMSPropOptimizer, are any additional variables added that need initialization?
Yes.
If yes, how can I get access to them and initialize them manually? (I'd rather not use tf.global_variables_initializer).
From the docs:
tf.train.RMSPropOptimizer.__init__(learning_rate, decay=0.9, momentum=0.0, epsilon=1e-10, use_locking=False, centered=False, name='RMSProp')
There are at least 3 (decay, momentum, and epsilon).
In other words: (1) How can I decide which initializer to use?
This I don't have a good answer to - I've been told in class "just use Adam". That might be good advice in general, but I imagine there are cases where others work better. This might be worth searching online for blog posts or survey papers or something.
(2) How can I add the initializer op to the graph, specifically for these variables?
You can pass them into the constructor as named parameters.
A little background: We're building a library/framework for working with scientific models. We have an interface Model which defines the operations that a model must implement, which is pretty minimal. That is: the Model interface defines the contract of a model from the point of view of a model implementor.
The framework adds a bunch of other functionality around the model, but right now client code has to access that functionality by using a bunch of other classes, such as ModelInfo, ModelHost, ModelInstance, etc.
In our application that uses this framework, we don't want to actually have to deal with all this mechanism of running models, etc. So we've decided to use the façade pattern to wrap up the framework functionality in an easy-to-use object. (We've already applied this pattern to other parts of the framework, with good success.)
Here is the question: given that we already have an interface Model, what would be a good name for the façade class? The Model interface is the contract between the framework and the model implementation, and the new class will define the contract between the framework and the client application.
Or, more generally: when we have an abstraction provided by a library or framework, how can we name the "two sides" of the abstraction so as to clearly identify the "provider" and "consumer" interfaces to the abstraction?
(If it matters, for this project we're using Java 6.)
I know this seems trite, but... have you considered using "ModelFacade" as the class name for the facade class? I think with documentation that indicates that the interface was already named Model, it seems relatively straightforward, and makes it very clear which design pattern you're using.
How about *Provider and *Consumer? I think you said it yourself in your question. Perhaps *Producer and *Consumer is a better match?
In discussions within our team, another option has been proposed: we can rename the existing Model interface to something else, and just call the new façade Model. In fact, they can both be called Model right now, because they will live in separate packages. (Although I'm not a fan of identically-named classes in different namespaces.)
Sounds like ModelInfo, ModelHost, and ModelInstance should all be members of Model.
See https://softwareengineering.stackexchange.com/questions/316840/is-it-bad-practice-to-name-a-class-with-a-facade-suffix for why you generally shouldn't name classes with the specific implementation used. Basically, some day you may want to use a different implementation of Model, which happens to not be a facade.
PureMVC uses a singleton named ApplicationFacade and registers all the models with methods like registerProxy which are defined in IFacade
In Domain Layer or Data access layer?
The primary motivation for DTOs is to present an interface tailored to another layer (typically, the presentation layer). For example, a data entry screen may need some bits of data from a User object in addition to some bits from an Order, etc. In that case, the Domain to DTO should happen at the layer which the presentation layer invokes, i.e., typically a "service" layer.
There are libraries like Dozer out there which automate the grunt work of converting between domain models and DTOs.
The key take away is DTOs are meant to abstract the data (not business logic) out of richer domain model objects - hence, DTOs should be converted back to domain objects as early as possible (at service layer) so the rest of your application layers may work with richer domain objects (data and business logic)
I'm not much of a fan of DTOs, but I say don't do it in the data layer. The data layer deals with model objects and their persistence. Why couple it with other layers by bringing DTOs into it? I'd map them somewhere else, probably between the service and ui tiers, just at the point where they cross the boundary between where they're created and where they're used.
Putting this in MVC context, if you have both controllers and services layer you should put it in the controller. This would make a DTO closer to the view layer and allow the service layer to play with domain objects only, avoiding possible confusion with other models.
The DTO itself is actually the MVC model (Explained here: https://stackoverflow.com/a/1058186).
Below is a recommended tutorial that mashes the controller, service layer and DTO concepts together (In java using Spring framework, but the concept is clear for other platforms as well):
https://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application
We are building a service-oriented system where we have separated the application into several layers:
SOAP web services (e.g., BuildingService.asmx)
Business logic layer (e.g., BuildingXXX)
Data Access layer (e.g, BuildingProvider)
Types (e.g., Building)
The SOAP web services simply instantiate an object of type BuildingXXX from the business logic layer in order to keep the implementation out of the SOAP web services. BuildingXXX then uses the BuildingProvider from the data access layer to return types defined in the data transfer object layer.
We have been unable to determine what we should call the objects in the business logic layer.
What is the "standard" naming convention for naming these business level entities?
Personally, I would call your business logic layer services "BuildingService" then call the web services "BuildingWebService".
Or you could always go with the generic "BuildingManager" as well for the service layer..
Namespaces are your friends. How about BusinessLayer.Building, BusinessLayer.Facility? Use DataLayer.Building, DataLayer.Facility, etc. You get to call things what they are, yet they get to be different things.
I would naively go with BuildingRules (since this is what they are, right?) but then I don't actually know what are the conventions...
i prefer prefixes instead of suffixes, so that the related layers sort together, e.g.
BizRuleBuilding,
BizRuleFacility,
...