I'd been looking at using the Rally API to create an app to do some simple auto-ranking stories based on specific criteria (at the request of / to help out a couple of our Product Owners) in a drag&drop workspace.
I did this by adjusting the "Rank" properties of the sequence of stories (I made sure to keep the rank values within the same overall min / max range as prior to the auto-reorder). I made a call to the API to update each story's rank individually (in quick succession).
Testing the app, I found that sometimes after running the auto-ranking app, some screens (such as the kanban board) would tell me that "drag and drop re-ranking is disabled for manual rank workspaces" (and the kanban would no longer let me drag & drop, although other screens such as the backlog would still let me drag & drop, and the workspace settings were still set to drag & drop). Deleting the stories, or reordering them on the backlog screen would return things back to normal.
After trying a few ideas to solve this, I figured perhaps if I was updating the Rank on a number of stories in quick succession, the back-end might be getting confused with these (potentially several / concurrent) requests. Introducing a delay between each story's API call has seemed to avoid the problem, and to speed things up, I now update a story's rank in the API only after the previous story's rank update has invoked the "updateComplete" function.
Do the assumptions in the last paragraph above make sense based on the backend ranking? Is there any Javascript API call to update multiple stories at once? (Otherwise I'm quite happy with the solution of only calling the API "update rank" after the prior API "rank update" call has returned ok).
That sounds like you discovered a possible issue with the backend ranking. The warning you were getting stems from the board trying to figure out which type of workspace you are in (manual or dnd rank). Since that setting is not currently available via WSAPI the board tries to figure it out based on its data and sometimes gets it wrong.
Currently there is no fully supported/documented way to adjust the ranks of items via WSAPI. The Card Board component in the App SDK uses special rankAbove and rankBelow query string parameters during update calls (which you can see in Firebug or the Chrome dev tools).
How are you currently setting the Rank values?
Related
For our Spartacus project, we need to introduce additional Data properties in the checkout:
We have the case, that the user needs to select a delivery mode per product.
In an ideal world, upon selection, the selected delivery mode would be saved in the NGRX Store and also in the Backend to stay within the principle of the data binding defined here: https://sap.github.io/spartacus-docs/connecting-to-other-systems/#component-data-binding
Expected Data / User flow:
User goes to Checkout and to Delivery Mode Step
Custom OCC Call is made to load the supported delivery modes for each product (depends on product type and further customer specific logic)
The cart items are displayed, enhanced with a dropdown containing the available delivery modes
The user selects a delivery mode
The selected delivery mode is stored on the cart entry within the NGRX Store and saved in the backend
The new Cart totals is calculated based on the costs of the selected delivery mode
The new Cart totals is stored on the cart within the NGRX Store and saved in the backend
The user clicks on continue to get to the Review Order Step
The cart items are listed with the previously selected delivery mode
After some analysis of the existing code, we found a property deliveryMode on the orderEntry. This does not seem to be used anywhere in spartacus, but could be used to make Step 9 work by following this stackoverflow answer and this one.
Questions regarding this flow:
How can we extend the NGRX Store? We assume, it would be possible to just extend the facade (Active Cart Service), bypass the store and save the information in the backend (Described here) and afterwards refresh the store from the backend. Is that Assumption correct? If yes, that feels awkward though, as we need to reload the whole store just to contain the new property deliveryMode on the orderEntry
How can we hook into the price calculation of the cart totals to update the total based on the selected delivery mode? And again, how can we bring the new total sum into the store?
There seem to be several Answers within the Slack Channel without very few usable answers around extending the ngrx store, even though for us, it seems to be a quit normal task.. :-/
Any thoughts, inputs or support would be very appreciated. :-)
This seems like a difficult thing to accomplish seeing as delivery modes per product aren't supported as-is in spartacus. But some ideas:
You can extend core CartEntry classes (adapter, connecter, facade, etc.) to include the delivery mode for entries added to the cart. You will probably need to change all to include the delivery mode setting(s). All of these are exposed so you can modify them as needed including the store.
Utilizing multiple carts to have a product per cart and set delivery mode that way. But this would be cumbersome in my opinion.
As far as price calculation goes, I'm assuming OCC calls return total prices. Does the call for the cart entries include delivery mode costs per entry?
We have implemented the following work around and it works so far:
Enhance the Cart Model in the backend
Add new Endpoints to load the available delivery Modes per Product (by bypassing the NGRX Store)
Add new Endpoints to save the selected Delivery Mode (by bypassing the NGRX Store)
After Save Endpoint, a cart Reload is triggered, which loads the new cart totals having a custom property on the order entry (via type augmentation) into the store from the backend
It's already a lot of years past since Spartacus project started, but looks like it's still really raw projects. Spartacus is not ready to deal with real word customer's requirement and complexity of customize it quickly grow at real project(so you start to think do we really need it, as it's so unflexible at some dimentions). Some parts is really hard or not possible to customize, so you begin to search a workarounds(This question is one common case).
I think NGRX Store is one of the biggest pain in the ass to customize something at Spartacus. 2 years past and nothing changed by Spartacus team...
I have a site similar to stack overflow where users can up and down vote posts. My question is how can I efficiently save this information to firestore under the Vuejs / Firestore/ VUEX architecture? How do other sites like stackoverflow/ reddit handle this?
I don't want to save directly on click because Firestore charges by the write and it would be very easy for a user to toggle up/ down votes many times consecutively. I also have a number of cloud functions this would trigger, each of which take time to complete.
I see a few alternatives. I could set a 2 second timer interval once a vote is cast, and if it doesn't change in that time, commit it to firestore. This has the downside of not working when the user leaves the page too quickly and after testing a few bigger sites, this approach seems to be of lower quality.
Another alternative is to save on page refresh/ exit with VUEX. Although the solutions I have found for this seem to rely on using the window object, which I hear may not work well if/ when I implement SSR into my app.
Perhaps there is a built in solution for this?
A common way to protect your back end against malicious users is to add a rate limit on certain events. In your case the up/down vote events.
Your first approach
You mention comes very close to the way rate limiting works. Just instead of firing the event to firestore 2 seconds after the user clicked and nothing has changed you could also fire the event immediately and then block any events for 2 seconds. This way the user can leave the page in the 2 seconds and the up/down vote will still be persisted in your database.
Your second approach
This is actually some I've never tried but just because you already mentioned the potential problems that come along in combination with SSR and the complexity of saving it to a temporary local state made me think that this approach might not be worth the work.
exaple solution
I copied this from a github issue comment, see the jsfiddle as an examp:
There are solutions you can do for per-user rate limiting using Rules
link to fiddle http://jsfiddle.net/firebase/VBmA
We've discussed exposing this information, but at present we don't expose quota, rate limiting, or billing metrics. There are likely better ways of configuring these things than Rules (which are primarily for authN/Z, resource definition, type validation). The worry about exposing them is having a proliferation of different config files (firestore.quota, firestore.billing, firestore.rules, etc.) that confuse users unnecessarily.
issue:
https://github.com/firebase/firebase-js-sdk/issues/647#issuecomment-380303400
I started modifying/developing Rally apps about a week ago using the existing Rally apps provided on the Github repository so far. However, for one of my final tasks I've been asked to recreate a tailored Defect Trend Report App and unfortunately, the source code is not available for the App. I tried to start from scratch but I've ran into numerous errors and am a bit overwhelmed.
I was wondering if anyone had the src code for the app or knew of a way to extract the src code from the existing app. Of course if there is custom code that an individual has worked on that could also help me progress in this process and wouldn't mind sharing it, that'd also help a ton.
I saw that there were a few snippets that could be used from the Hackathon repo, but they're not quite on the mark of what I want to do with the app. I'm just trying to have the existing app filtered by delivery versions (currently filtered by iteration/release).
All help is greatly appreciated.
Thanks fellas!
There is an example of a 'bare metal' chart app in the App SDK 2.0 docs. It should give you the basics on how to do a chart.To get to it, go to the help pages (click on avatar in top right corner) and search for "Rally App SDK"
After that, you need to work out how to select defects from the various releases and do a count of each. There are two ways to do this:
Get all defects in the project you are in (don't forget whether you need to scope down to child projects too) and then do something like _.uniq() on the release field to find the list of releases (or do another request to get all the releases into a different store and use that for names and a count).
Get the releases and then for each release request the related defects.
If you do ask for child projects, you will need to handle all the scenarios of different releases for different projects - can get complicated!
#1 is effectively one big fetch, #2 may be many smaller ones.
You may want to decide whether to count all defects, sum the estimates, ignore those not finished, etc., etc.
Rearrange inventory of specific game in steam? is it possible or not?
I checked steamworks and steam api for some information but there is nothing about it, only getting items not changing positions.
There is not an API for this functionality. There is, however, a pull request to the (TF2 centric) SteamBot application that adds this functionality to that project. One thing to be aware of, though, is that this pull request is 7 months old and hasn't been merged in by the project developers. In that time, Valve has made changes that required SteamBot changes due to underlying Steam network changes. This request may or may not work any more. It may give you an idea of what needs to be done.
I have 2 1/2 years experience of VB.Net, mostly self taught, so please bear with me if I seem rather noobish still and do not know some of the basics. I would recommend you grab a cup of tea before starting on this, as it appears to have got quite long...
I currently have a rather large application (VB.Net website) of over 15000 lines of code at the last count. It does not do retail or anything particularly complex like that - it is literally just a wholesale viewing website with admin frontend, catalogue / catalogue management system and pageview system.
I don't really know much about how .Net applications work in the background - whether they are all loaded on the same thread or if each has its own thread... I just know how to code them, or at least like to think I do... :-)
Basically my application is set up as follows:
There are two different areas - the customer area and the administration frontend.
The main part of the customer frontend is the Catalogue. The MasterPage will load a list of products but that's all, and this is common to all the customer frontend pages.
I tend to work on only one or several parts of the application at a time before uploading the changes. So, for example, I may alter the hierarchy of the Catalogue and change the Catalogue page to match the hierarchy change whilst leaving everything else alone.
The pageview database is getting really quite large and so it is getting rather slow when the application is first requested due to the way it works.
The application timeout is set to 5 minutes - don't know how to change it, I have even tried asking this question on here and seem to remember the solution was quite complex and I was recommended not to change it, but if a customer requests the application 5 minutes after the last page view then it will reload the application from scratch. This means there is a very slow page load whenever it exceeds 5 minutes of inactivity.
I am not sure if this needs consideration to determine how best to split the application up, if at all, but each part of the catalogue system is set up as follows:
A Manager class at the top level, which is used by the admin frontend to add, edit and remove items of the specified type and the customer frontend to retrieve a list of items of the specified type. For example the "RangeManager" will contain a list of product "Ranges" and will be used to interact with these from the customer frontend.
An Item class, for example Range, which contains a list of Attributes. For example Name, Description, Visible, Created, CreatedBy and so on. The form for adding / editing loops through these to display relevant controls for the administrator. For example a Checkbox for BooleanAttribute.
An Attribute class, which can be of type StringAttribute, BooleanAttribute, IntegerAttribute and so on. There are also custom Attributes (not just datatypes) such as RangeAttribute, UserAttribute and so on. These are given a data field which is used to get a piece of data specific to the item it is contained in when it is first requested. Basically the Item is given a DataRow which is stored and accessed by Attributes only when they are first requested.
When one item is requested from a specific manager is requested, the manager will loop through all the items in the database and create a new instance of the item class. For example when a Range is requested from the RangeManager, the RangeManager will loop through all of the DataRows in the Ranges table and create a new instance of Range for each one. As stated above it simply creates a new instance with the DataRow, rather than loading all the data into it there and then. The Attributes themselves fetch the relevant data from the DataRow as and when they're first requested.
It just seems a tad stupid, in my mind, to recompile and upload the entire application every time I fix a minor bug or a spelling mistake for a word which is in the code behind (for example if I set the text of a Label dynamically). A fix / change to the Catalogue page, the way it is now, may mean a customer trying to view the Contact page, which is in no way related to the Catalogue page apart from by having the same MasterPage, cannot do so because the DLL is being uploaded.
Basically my question is, given my current situation, how would people suggest I change the architecture of the application by way of splitting it into multiple applications? I mean would it be just customer / admin, or customer / admin and pageviews, or some other way? Or not at all? Are there any other alternatives which I have not mentioned here? Could web services come in handy here? Like split the catalogue itself into a different application and just have the masterpage for all the other pages use a web service to get the names of the products to list on the left hand side? Am I just way WAY over-complicating things? Judging by the length of this question I probably am, and it wouldn't be the first time... I have tried to keep it short, but I always fail... :-)
Many thanks in advance, and sorry if I have just totally confused you!
Regards,
Richard
15000 LOC is not really all that big.
It sounds like you are not pre-compiling your site for publishing. You may want to read this: http://msdn.microsoft.com/en-us/library/1y1404zt(v=vs.80).aspx
Recompiling and uploading the application is the best way to do it. If all you are changing is your markup, that can be uploaded individually (e.g. changing some html layout in an aspx page).
I don't know what you mean here by application timeout, but if your app domain recycles every 5 minutes, then that doesn't seem right at all. You should look into this.
Also, if you find yourself working on various different parts of the site (i.e. many different changes), but need to deploy only some items in isolation, then you should look into how you are using your source control tools (you are using one, aren't you?). Look into something like GIT and branching/merging.
Start by reading:
Application Architecture Guide