I am new to reactive programming and trying to learn by developing an Angular + RxJs app. The idea of the app is to mimic github features like Manage repo, Manage branches, etc.. This app will have a left nav that will display all the repo(s) associated to the logged in user, clicking on the repo will bring all the branches associated to the repo, clicking on the branch will bring all the files under the branch. User can add/edit/delete branch, add/edit/delete files in a branch (the usual use cases...) basically a lazy loading concept.
My Data Model
Repository
-----UserDetails
-----Array[BranchArtifact]
-------------Array[Files] called currentElements
-------------Array[Files] called changedElements
-------------Array[Files] called conflictElements
Idea 1:
Have a BehaviorSubject<Array<Repository>> / method1() that will return the connected Observable<Array<Repository>> which can be subscribed in the component that will render the Repo level tree navigation nodes (This rendering part will be repsonsible for just the repo level operations like add/del repo)
Have a BehaviorSubject<Array<BranchArtifact>> / method2() that will return the connected Observable<Array<BranchArtifact>> which can be subscribed in the component that will render the Repo level tree navigation nodes (This rendering part will be repsonsible for just the Branch level operations like add/del Branch)
... and so on for each lazy loaded level
This idea feels like the nested object is flattened at the stream level but then on the UI side is still indirectly managed in a nested fashion (as each nested level will have to tie back to its parent node)
Idea 2:
Have one BehaviorSubject<Array<Repository>> / Observable<Arra<Repository>> and on every click on the tree node fetch the desired sub level data, update the subject with the returned value and let the subscribers infer the updated data (as the stream will always emit a Repository(s) object) and manage the UI accordingly (may be emit a change type to ease the subscribers work). This feels more like an imperative programming style... In this design the UI logic will have to navigate to the correct node to manage it for every value emitted in the stream.
I have gone tro a lot tutorials, videos and tech talks on this subject and couldn't find anything beyond a basic data structure example. Any help is greatly appreciated...
Question to experts here,
Are these ideas any good
Am I thinking reactive
If i am totally off base here please point to something that will help me understand...
If there is something simpler please suggest
When making a commit, i wanted to know if we could require all users to add more than only 3 characters so we dont get commits within GITLAB that are like "..." because the user didnt feel like added a note in.
Please use GitLab Push Rules:
https://docs.gitlab.com/ee/push_rules/push_rules.html
Push Rule:
Restrict by commit message
Only commit messages that match this regular expression are allowed to be pushed. Leave empty to allow any commit message. Uses multiline mode, which can be disabled using (?-m).
Restrict by commit message (negative match)
Only commit messages that do not match this regular expression are allowed to be pushed. Leave empty to allow any commit message. Uses multiline mode, which can be disabled using (?-m).
How to implement into your organization
You really don't want to check that a commit message does not equal "...".
You usally want to align with your team on a process like "no commit without a (Jira/Bugzilla/Redmine/Kanbanize/etc.) ticket. Commit messages starts with a ticketnumer, e.g. "PRJ-1234: blablabla"
Of course everybody has his/her stupid tasks, where one might be lazy on setting a commit message. But for the 99% important commits, you should talk about the users feelings. Maybe you should get rid of them.
In TortoiseGit you can configure a minimum size for the commit message (this is, however, only enforced when using TortoiseGit; cf. https://tortoisegit.org/docs/tortoisegit/tgit-dug-settings.html#tgit-dug-settings-dialogs3)
When you store this to the project level and commit /.tgitconfig this setting will be effective for all TortoiseGit users of the repository.
TFS Web-client provides a "board" view under the backlog tab which shows the sum of Remaining work for a User Story based on the Sum of Remaining Work for it's child tasks.
I have also tried exporting to Excel and using a Pivot table, but there are no obvious links between the work items (as far as I can tell).
I saw this question but I can't tell if that is the same idea.
Also, this item might be similar, but no responses were received yet.
Can it be done out-of-the-box in Visual Studio TFS?
Does it require coding?
Are there plugins available? I've looked at TFSAggregator on Github and that might work but I'd like to avoid server-side plugins if possible.
One of the many uses of TFS Aggregator... it is even one of their sample use cases!
Example Uses
Update the state of a Bug, PBI (or any parent) to "In Progress" when a child gets moved to "In Progress"
Update the state of a Bug, PBI (or any parent) to "Done" when all children get moved to "Done" or "Removed"
Update the "Work Remaining" on a Bug, PBI, etc with the sum of all the Task's "Work Remaining".
Update the "Work Remaining" on a Sprint with the sum of all the "Work Remaining" of its grandchildren (i.e. tasks of the PBIs and Bugs in the Sprint).
Sum up totals on a single work item (i.e. Dev Estimate + Test Estimate = Total Estimate)
You can rollup estimated and actual work using Project. Because Microsoft Project has a scheduling engine, it automatically will generate a rollup of summary tasks. Rollup provides summed values of select fields for all child work items of a parent. https://msdn.microsoft.com/en-us/library/dn769080(v=vs.140).aspx
I've been able to do this, however there is an issue when a Task's State value is set to "Removed", the rollup values should not be calculated for that Task. In the policy file, I've got the if condition like so:
<rule name="RollupTasks" appliesTo="Task"><![CDATA[
string wfState = (string) self.Fields["State"].Value;
if (wfState="Removed" && self.HasParent()) ...
But that didn't work. I've also tried:
<rule name="RollupTasks" appliesTo="Task"><![CDATA[
if (self.HasParent() && self[System.State]="Removed") ...
..but this doesn't seem to work. Am I close?
The team I manage has been using TFS for years, but we've used a 3rd party system for tracking bugs and features. I'm looking to upgrade our team into TFS 2013 and I've done tons of reading and research into how TFS manages work items, backlogs, iterations, tasks etc. And although I understand the principles of what 'can' be done, I'm having a hard time visualizing 'how' our team would work with these work items as tasks.
If anyone knows of any best practice guides for actual sample based usage, or can answer any of these questions that'd be great
1) Product backlog - Under the 'configure schedule and iterations' what is the concept for setting the current 'backlog iteration'? Our team uses short 2 week iterations with a build number, but setting the build iteration as the current backlog makes all new PBI's scoped to only that iteration. Any items not complete in that iteration would disappear once I set the current build to the next iteration number. On the other hand, if I set it to the parent root node, I could see the PBI list getting rather large over time. What is the best method for managing PBI's that are unassigned and working in a simple Parent->build1/build2 etc structure?
2) Features - So I create a feature, perhaps it spans many work items and several tasks. They get completed over time, but I've noticed there's no 'auto' complete or status updates on parent items. So who/when is a Feature item supposed to get marked complete? If the product owner is supposed to use the features list to get an overview of work, they have no idea if all the dependent items have been complete and when to mark the feature Done.
3) Work Items - Managing these, and in particular their 'state' or status seems like a royal pain. On the task board you can't change their state, only their tasks with drag-drop, which is nice. But you complete all the tasks, and the parent work item stays in status 'New'. Do you really have to micro-manage every work item, open it up, and set the state to Done?
4) QA/testing - For every work item, each team member is responsible for testing each item, so every item is tested by multiple people, and logging any issues found. What's the best way to use work items or tasks for this?
5) Build Complete - Once every work item in the iteration is marked Done then I assume they are removed from the product backlog correct? The exception to this seems to be the features they were tied to, the feature item itself remains open. How do stakeholders view a list of features that were completed in the current build?
I can't answer everything (indeed, there is no one "right" answer), but here's how my team uses TFS - it might give you some ideas:
We use Area Path to represent a Project or Epic that work belongs under. When a work item is created it is assigned to a project using the Area Path, and it never changes.
Then to represent "when" work is done we use a hierarchical iteration path under 3 headings (for a project called "Project"): Project\Completed, Project\Current, Project\Future.
Stories in the product backlog are initially assigned to Future (We go a bit further in fact and use New stories to represent "proposed" work, and Active ones to represent the "approved" backlog - this allows us to plan tentative projects/contracts that convert into real work when they get the green light). At this stage we do Planning Poker to get Story Points and then the Project Managers assign stack ranks to the stories to help to decide what to move from Proposed to Product backlog, and then eventually what we should think about for the next iteration.
When we start an iteration we create a new iteration (call it 001) under Future, i.e. Project\Future\001. Then Stories are chosen from the Product Backlog for implementation - they get assigned to this iteration. When the iteration is ready to start, we use a "conveyor belt" approach which moves all the iterations along one "place" in the hierarchy: In the Iteration Path configuration UI, just drag the 001 iteration from Future to Current. This re-paths everything in that path automatically so that all the active work is instantly under Project\Current.
As we complete the iteration, we would have Current\001 and we'd then add Future\002. Then we move 001 and 002 along the conveyor (to Project\Completed\001 and Project\Current\002 respectively). This way the work gets assigned to one iteration and stays there, but the iteration as a whole moves from future ...to current ...to completed. This allows us to build queries like "all current work" (all work under "Project\Current") that we don't need to rewrite for every iteration, and this saves a massive amount of time and eliminates a lot of mistakes trying to re-assign iteration paths constantly - in most cases the iteration is only changed once (from future to an actual iteration).
When a story moves into the current iteration, we choose an implementing team (e.g. an owner to accept delivery, and a developer and a tester to implement the work) and those people add tasks for any work that needs to be done to deliver the story. Any bugs/issues that crop up for that story during the iteration are also parented to the Story or Tasks.
We found the TFS tools pretty poor (clumsy, slow, micro-managing), so we now use a home-built dashboard that shows us a list of stories, so in our scrum we can step through the stories and see the tasks/bugs/issues for each, who is working on them, and how much work they reported on the task since the last scrum. This gives us a really clear basis to discuss the story.
We close tasks/bugs/issues as we complete them, but the story stays open till the end of the iteration (so that any new bugs found can be attached and dealt with). We then use a custom tool to "Resolve" the story, which closes all the child work items, and then checks if the parent Feature or Epic is now completed and can also be marked "Resolved". This can also be done in stock TFS just using a manual process, but it is rather laborious, and the code to automate it is only an hour or two's work. I really don't understand why TFS makes you essentially update all the database tables by hand when it's so easy to automate. (In a similar way, the TFS kanban is unnecessarily time consuming to manage because items only appear on it if they are perfectly formed - get any of the estimate, remaining, completed, area, iteration, assigned-to, parent link, etc wrong and it vanishes! So I've written e.g. a simple 'create task' tool that asks for the estimate, assignee and title, and fill in the rest - this took me a couple of hours to implement and has eradicated all the time consuming errors and hassle of using TFS 'raw')
When processing tasks, TFS provides 'Activity' states (planning, development, testing, documentation etc) - which implies that each single task will be passed linearly through a chain of different people to be implemented... but we feel this is a poor approach, because we want to encourage the team working on a story to work in parallel and work together, not "throw their bit over the fence to the next guy". So instead each person on the team creates one or more tasks under the story that represent the parcels of work (programming, testing, documenting) they must personally do to deliver the story, and each task only ever has one owner. (This works well in our scrum dashboard because it shows the story and its list of child tasks/bugs/issues, so the entire context of the story's work can be seen easily at a glance). The separate tasks allow the programmer and tester to work together in a tight, iterative, co-operative agile loop, often with progressive roll-out of parts of the feature for testing, rather than the programmer finishing all his work before passing the complete article over to the tester in a waterfall-y way. At the end of the iteration, the story-team demos their story to the wider development team, and they are all equally responsible for ensuring that everything needed is delivered. After the demo, the Product Owner/Champion then accepts the work as done (or rejects it). This vastly reduces the amount of work that gets dropped "between the cracks" where people think somebody else will do it, helping us to get to a solid delivery at the end. We've found communication within the team and story delivery significantly improved since we moved to this approach.
I should mention that to get good estimates and burn-downs we try to keep each task less than 5 days work, and to avoid micro-management we try to avoid splitting down tasks into anything under about 2 days (though obviously some tasks are necessarily shorter).
As I've mentioned, we log bugs/issues as children of the task or story they affect (and can also add Related links if they impact more than one story). At the end of the iteration as well as demoing the new features to the rest of the team, the release build is regression-tested as a whole. Any bugs found are fixed in a release branch and within (hopefully) a day or two we have a stable customer release. We aim to have a product of customer-releasable quality from every iteration, and to keep the number of outstanding bugs per developer below 5 (usually 1-3). Before introducing this system, we had an ongoing average of 20 bugs per developer, an unpleasant technical debt. (Note: we reserve some time in every iteration for fixing these bugs, but when bugs are too gnarly to fix then-and-there, we usually convert them into new stories so that they can be estimated and scheduled for a future iteration just like other work, so the bug-list and technical debt is never allowed to build up, and where possible bug fixing is not allowed to derail our iteration plan.
We don't treat work in progress (items in an iteration) as Product Backlog - the product backlog is work that we plan to do in the future, and when it moves into an iteration it becomes actively worked on and no longer in the "to do" list (it's the Iteration backlog, not the Product backlog). When all of the work (task/bug) is complete, then the parent story can be Resolved ('we think it is "done"') and then Closed ('the Product Owner accepts it as "done"') and so a simple query (work under Project\Current that is Closed) will tell you what you have delivered this iteration.
Lastly when we close out the iteration, the whole iteration moves into Project\Completed, so then you can easily query all of the work which has ever been completed (under Project\Completed), and still grouped within their individual iterations. So at any time if you want to know what "Build 107" added, you can just do a query for all Closed stories under iteration path Project\Completed\107. We mark incomplete/abandoned work as Removed, so for us Closed means "Done". If work is not completed in one iteration and is continued in the next, then we simply move the story to the next iteration, and so the completed work then shows up in any queries for "Build 108" instead - so this perfectly tracks the achieved deliveries for an iteration.
To keep things consistent, only a few team members can change different types of item. So our "planning items" (Epics, Features, Stories) are only changed by the Project Manager or Product Owners. Tasks are all owned and thus created/changed/closed by the developer that is doing the work. PMs track progress of stories and devs track progress of tasks.
1) Product backlog - Under the 'configure schedule and iterations'
what is the concept for setting the current 'backlog iteration'? Our
team uses short 2 week iterations with a build number, but setting the
build iteration as the current backlog makes all new PBI's scoped to
only that iteration. Any items not complete in that iteration would
disappear once I set the current build to the next iteration number.
On the other hand, if I set it to the parent root node, I could see
the PBI list getting rather large over time. What is the best method
for managing PBI's that are unassigned and working in a simple
Parent->build1/build2 etc structure?
TFS has two different backlogs. The Product Backlog of your team and the Sprint backlog of your team. In the iteration configuration screen you define which iteration contains your teams product backlog (by setting the Backlog iteration) and which iterations below that will represent your sprints .
If you have a large list of PBI's you could put these either in an iteration above the current backlog iteration, which will effectively hide them from the backlog pages. Or you can place them in a separate iteration that is a sibbling of your Backlog iteration.
2) Features - So I create a feature, perhaps it spans many work items
and several tasks. They get completed over time, but I've noticed
there's no 'auto' complete or status updates on parent items. So
who/when is a Feature item supposed to get marked complete? If the
product owner is supposed to use the features list to get an overview
of work, they have no idea if all the dependent items have been
complete and when to mark the feature Done.
There is no auto-complete or auto-close. Normally the Product Owner (scrum role) will keep an eye out on what he has requested and knows just about when a feature is about to be completed.
You can also view the hierarchy of Product backlog items to features in the Product Backlog view by selecting the Features to Backlog Items view. This will also list the states of the underlying stories:
3) Work Items - Managing these, and in particular their 'state' or
status seems like a royal pain. On the task board you can't change
their state, only their tasks with drag-drop, which is nice. But you
complete all the tasks, and the parent work item stays in status
'New'. Do you really have to micro-manage every work item, open it up,
and set the state to Done?
Normally the product owner/project manager will approve stories for pickup and move them from new to approved. Then during the Sprint planning meeting (or at the start of a sprint), the team selects which items they will work on and will move these from Approved to Committed.
Then at the end of the sprint (or when all tasks under a story are done), the development team shows the product owner the finished work and then moves the story to done as well.
4) QA/testing - For every work item, each team member is responsible
for testing each item, so every item is tested by multiple people, and
logging any issues found. What's the best way to use work items or
tasks for this?
Depends on the maturity of the team. And depends on your adoption of Test manager (Test Case work item). If your team is pretty mature and is using Test manager to link Test Cases to your Stories, then you can view the status of your tests in Web Access. If the team consistently works in a ATDD way of working, they'll do the work needed to make a test succeed before moving on to the next piece of work. In such a workflow it's not really needed to create "design-build-test" work items. The work item would probably be akin to "Make test X pass" and would include all the work to create the test, build the code and make the test pass.
5) Build Complete - Once every work item in the iteration is marked
Done then I assume they are removed from the product backlog correct?
The exception to this seems to be the features they were tied to, the
feature item itself remains open. How do stakeholders view a list of
features that were completed in the current build?
Again, use the Feature to Product Backlog Item view to see which features have had all their work finished. The stakeholders mentally verify that this was indeed all they wanted and that they have no additional requests, work, feedback that is needed to truly complete the feature. If this is the case they will close the feature by moving it to done.
db 11gxe and apex 4.x
i created a master detail page , there are buttons on it by default , like (cancel,delete,apply changes) and two buttons for getting the next order and the previous one --there a master table for orders .
there are also branches created by default for the button getting the next order and the button getting the previous one (the branch is conditional ofcourse) -- the condition is when-button-clicked .
these branches are created automatically because the buttons are exist , and there are conditions which are "when-button-clicked" --just this condition .
-- what i do not understand is that there are other buttons like "delete , cancel , apply changes" , and there were no branches created for them like the other buttons which i mentioned above ,
although they also navigate like the other buttons , and the condition is when-button-clicked as well ?
why in the first situation there are branches created automatically , and in the last situation there are not ??
thanks in advance
Firstly, if there is a final "Default" branch (i.e. one with no conditions and not attached to any button), it will be used if no other branch is applicable.
Secondly, there are multiple points where branches can happen, and it depends on how much processing should be done before the branch is done.
Typical branches are in the "After Processing" section, which means all applicable validations and processing are done before the branch.
A "Cancel" button, however, typically doesn't want to do any validations or processing, so the button may have its Action set to "Redirect to URL" - so no branch is needed.
Alternatively (although rarely, in my experience), a Branch may be added to the "After Submit" section, which would skip any subsequent validations and processing. Or, it might be created in the "Processing" section, which would allow validations to be done but subsequent processing to be skipped.