I would like to know if there is an internationally recognized best practice for naming queues?
My question is probably easiest to understand with an example:
Someone uploads an image and I add a message to a queue because I want to make a thumbnail but I don't want to make the uploader wait for the thumbnail to be created.
Now the queue contains a message with the id of the uploaded file and it is implicit for me that the purpose of this message is to create a thumbnail.
So do I name it based on what just happened?
image-uploaded
Or do I name it based on what I want to happen to items from the queue?
create-thumbnail
Almost like a method name?
Or do I name the queue by what it contains?
image-ids
And bonus question ... because I am expecting that best practice is to name it after what I want to use it for, like "create-thumbnail" - so what happens if I also want to add metadata? Then the queue will be wrongly named.
Should I then create ANOTHER queue and call it "set-image-metadata"?
But now I have two queues and letting a naming convention get in the way of my software. Because I probably want to both create the thumbnail and set metadata in one queue trigger because when I have the image loaded anyway, that would be most efficient.
So is it better to name it something more generic like
image-post-processing
I am interested in two aspects here:
How should I name it in reference to the examples above?
Should I include something like the class name or queue trigger that it belongs to or something like that? Because in one way, the queue doesn't know who it belongs to - but in reality in my software design it is very tightly coupled to a specific queue trigger, so shouldn't I indicate that somehow on the queue?
Thank you very much for your insights.
(Stackoverflow might deem this question to be too subjective but I have gained great value from finding questions like these in the past - but for the sake of objectivity, it would be great if you could reference authoritative sources)
The general rule is that you should name variables after what they represent. How a variable is used may change. In this case "uploadedImages" would be an appropriate name.
Related
As I am not sure I stated the question very well originally, I am restating it to see if there is a better response.
I have a problem with how best to manage a specific kind collection with a RESTful API. To help illustrate the issue I have I will use an simple artificial example. Lets call it the 'Raffle Ticket Selector'. For this question I am only interested in how to perform one function.
I have a collection of unpurchased raffle tickets (raffleTickets). Each with a unique Raffle Number along with other information.
I need to be able to take an identified number of tickets (numTickets) from the raffleTickets collection without uniquely selecting them. The collection itself has a mechanism for random selection.
The result is that I am returned 5 unique tickets from the collection and the size of the collection is decreased by 5 as the 5 returned have been removed.
The quesition is, how do I do it in a RESTfull way?
I intuatively want to do METHOD .../raffelTickets?numTickets=5 but struggle with which HTTP Method to use
In answering; you are not allowed to suggest that I just PATCH/PUT a status change to effect a removal by marking them taken. It must result an actual change in the cardanality of the collection.
Note: Calling the method twice will return a different result set every time and will always alter the collection on which it is performed (unless it is empty!)
So what method should I use? PUT? POST? DELETE? PATCH? Identpotent restrictions would seem to only leave me with POST and PATCH neither of which feels ideal to me. Or perhaps there is another way of providing the overall behavior that is considered the correct approach.
I am really interested to know what is best practice and understand why.
Cheers
Original Post on which the first response was based:
I have a pool of a given item which is to be managed with a RESTful API. Now adding items to the pool is not an issue but how to I take items from the pool? Is it also a POST or is it a DELETE?
Lets say it is a pool of random numbers and I want to retrieve a variable number of items in a single method call.
I have two scenarios:
I am not checking them out as once taken they will not be returned to the pool.
I only want to check them out and they effectively remain part of the pool but have a status altered to 'inUse'
The important thing in each case is I do not care which items I get, I just want N of them.
What is considered the RESTful way performing each of the two actions on the pool? I have an opinion on the second option but I dither on the former so I am interested in your thoughts for both so I better understand the thought pattern
Thanks
Not sure if I understood well your question. It will mostly depend on the way you developed the API side of your REST communication.
In a generic solution, you would use DELETE to take items out of a list. However, if you just want to PARTIALY update the items, you could use PATCH instead of POST or PUT.
Give this a look: http://restcookbook.com/HTTP%20Methods/patch/
I try to design database tables for the case shown below. I also have an account defined, but it's not important regarding my problem.
There is a list of operations (expenses). Each operation can take place in specified POI, places can be grouped in chains (optional). Each operation can have a recipient, specifically a shop chain.
My current design looks like below. I could even remove chain table in favor of direct reference to recipient, but it still leaves a loop between tables. Effectively, single row could contain references to place and receiving account having different recipient defined.
The only solution I can see is a table check to exclude described case, but I'm wondering: is there a better fix?
As far as I can tell there isn't anything fundamentally wrong with your design. There's no need to change it just because it contains a loop. The loop in this case doesn't even appear to be a circular dependency. If you believe your current design accurately models what it is intended to then I see no need to change it.
Venue 1 may use a a specific message to request say Market Data, whilst venue 2 may use another message for the same task. Now what is the best way of mapping this? Any suggestions would be appreciated
Plus is it sensible to append extra fields to a venues message, to make mapping easier?
Can anyone provide insight on how an exchange performs this task? As an exchange which is connected to multiple venues must surely have to parse and translate each venues spec.
Unfortunately, the flexible nature of FIX doesn't really make this an easy task. My other answer goes into more detail on why converting between FIX versions is not feasible and how two venues using the same FIX version can actually be radically incompatible.
In my experience, you really have to write a custom adapter for each venue. One way is to create a venue-independent set of data objects for your app to use, and then implement conversions between your objects and the FIX messages to/from the venue. The app would see the converter as only a generic interface; it doesn't need to know whether the target venue is 4.2 or 4.4 or whatnot.
For instance, you could create a GenericNewOrder class and an IConverter interface with a method SendNewOrder(GenericNewOrder). The IConverter has an implementation for each venue, e.g. VenueAConverter and VenueBConverter. VenueAConverter creates a new order message appropriate for VenueA, and VenueBConverter creates one for VenueB. If you ever have to add a new venue, just implement a new IConverter.
That's the best pattern I've been able to come up with.
(Questions like yours actually come up semi-frequently on the QuickFIX mailing lists.)
I like knockoutjs, the sooner we get rid of coding directly toward the DOM the better. I'm having trouble understanding how I would do something which I'm going to explain in terms of a question/answer site. (This is probably a general MVC/MVVM question)
In my data model I have a question[id, description] and answer[id, question_id, text]. The browser requests a list of questions which is bound to a tbody, one column will display the question description, while the other should be bound to an answer textbox.
One obvious way of doing this is to have a QuestionAnswer[question_id, answer_id, question_descrition, answer_text] model. Ideally I'd like to keep them separate to minimize transformation when sending/receiving/storing, if there isn't some way of keeping them separate then I have the following question:
Where is the ideal place to create the QuestionAnswer model ? My bet is that by convention its created on the server.
If there is such an example somewhere please point me to it, otherwise I think it would make a good example.
Please help me wrap my head around this, Thanks!
What you could do is to create the combined model on the server, serialize it to json and then use the mapping plugin to add the serialized list to the view model.
I'm doing that here only it isn't a combined model, but shouldn't make any difference. Especially since it seems like your relation is one-to-one.
If you need to create an "object" in your view model, you can use the mapping definition to do so, like I do here.
I use C# to build my model on the server, but I guess you can use whatever you are comfortable with.
The cool thing with the mapping plugin is that it adds the data to the view model so that you can focus on behaviour.
Ok,
I'v gathered my thoughts on what my question is actually asking.
To do data binding on the client side you obviously need your data model there as well. I was conflicted on what I needed to send over and at what time.
To continue with the Question/Answer site idea: Sending down a list of answers each of which have a question in them is what should be done. That way you can bind to the answer list and simply bind the question description of each answer to the first table column.
If later I want to make a question editor I would potentially send a complete different data structure down and not reuse the Answer has a Question structure previously used.
I thought there might be a way of sending down a more complex data structure that references itself. Which apparently is possible in JSon with some extra libraries.
there would be users with different privilages and as a consequence there would be a lot of conditions, so how can i model the conditions in the use case diagrams? for example, the forum manager may create a post or update a post or even delete a post, create a threads or update avialable threads, delete threads, etc.
1- should i have different "use case" elements for each task? i mean add an oval/circle element for each task?? like creating an oval for "create a post", an oval for "updating the post",.....
2- is it correct to have one actor for each privilage?? like one for anonymuse user, one for logged in user, .....
thanks.
You shouldn't get into conditions and ifs and buts in use cases diagrams. A set of use cases is intended to provide an overview of the system's functionality, and each use case describes an interaction between the system and one or more actors. You want to keep that description simple and succinct.
Each use case should in some way make sense to the actor. To a person using a forum, it does make sense that creating a post is a separate activity from updating one (or responding to one), so that seems like a sensible start to me. You should not be overly concerned with the number of use cases at this stage. The number of use cases does not translate directly into system complexity, and a large number of clearly defined use cases is better than a small number of large, ambiguous ones.
The next step is to elaborate your use cases, and that's where you can start talking about conditions. Elaboration is typically done using an activity diagram which describes how the interaction between the actor and the system proceeds, eg Poster initiates post; System checks poster's privileges; System rejects post if privileges are insufficient; etc.
There is of course no right or wrong, but generally speaking it's a bad idea to use actors such as "logged in user" etc, and in fact you should avoid employing a "user" actor at all. Why? Because the interaction is actually between the system and a person, whereas a user (account) is an in-system representation of a person's privileges.
In other words, if you find yourself using actors which are in fact concepts from within the system, you've taken a wrong turn somewhere. Every use case must involve a system-external actor, otherwise you're not describing the system from the outside.
A better set of actors for a forum system would probably be Poster, Reader and Manager (and possibly a System Administrator as well).