Trying to categorize Hadoop's schedulers (not only the official FIFO-Capacity-Fair) i seem to find that there is no clear understanding as to what each of the 4 categories that a Scheduler can belong to, are defining as a behavior control.
The 4 Categories i seem to conclude are:
• Static Scheduling
• Dynamic Scheduling
• Resource Availability
• Time Awareness
Can someone point me into a direction or a source i am not aware of, in order to find out more, or clarify on it's own the above?
While researching into this more i came to the following conclusion, which i am posting in order to help.
A Scheduler can belong in 2 Categories. Static Scheduling(FIFO,Fair,Delay,Capacity) and Dynamic Scheduling(Deadline Constraint, Resource Aware).
After choosing the desired scheduler, the tuning of various properties inside YARN's code, can define if that Scheduler will work based on Resource Availability(Delay Scheduler, Matchmaking Scheduler, Resource Aware) or based in the Time(Deadline Constraint, Delay) constraint.
Again this is an understanding of mine through some research that i have done.
Related
According to "Head First Object-Oriented Analysis and Design", Complex projects involves first finding a feature list -> drawing use case diagrams -> breaking into smaller modules before implementing object oriented design (requirements gathering -> use cases -> OO -> design patterns etc.)
I want to understand, what is the criteria for the size of project when feature lists and use case diagrams should be implemented before finding requirements and writing use cases?
I am particularly interested in how can this knowledge be applied to my real wold problems
Example, I am working on a UI that send instrument commands to the server and displays the response back from the server. I know from customer feedback that the UI should have the following things:
It should be able to let the user select an instrument from available list and send any custom command and display the result
It should be able to let the user select an instrument and a command from available list and display the result (create commands using drag and drops from given lists)
It should be able to have capability of creating macros
Is this UI project small enough to not have steps for gathering features and drawing use case diagrams? Do we go straight to categorizing the asks as requirements and start gathering requirements and writing use cases?
How would one go about breaking down project of this nature to deduce it to its appropriate class diagrams?
I have tried considering the above mentioned asks as features and then tried creating requirements, mainly on the different states that one could have during the life cycle of the UI application but I am still not sure and unable to comprehend the teachings of the books on this project.
I haven't read the book, so I'm not sure what the author(s) of the book really wanted to emphasize here. But I assume that you misinterpreted it.
Without knowing the requirements there is no feature list. If you don't know what is needed then you can't say anything about the system's capabilities.
Gathering requirements is an iterative process. First you gather the high-level requirements in order to be able to start building a mental model about the system. This can help you to start think about the supported features. By sharing your mental model and the exposed feature set of the system with the stakeholder, it initiates the next iteration.
Here you can start talking about actors, user journeys, use cases, etc. These are mainly focusing on the happy paths. As you have more and more iterations you will reach a point where you can start talking about edge and corner cases: What suboptimal cases can we foreseen? What can we do (prevention, detection, mitigation)? How does it affect the system/actors/journeys?...
The better you understand the needs and circumstances, the better the design and implementation of the system could be.
UPDATE #1
Will we always have high-level and low-level (edge cases and detailed use cases) requirements i.e. we will first need to make use case diagrams and then write individual detailed use cases?
There are a lot of factors which can influence this. Just to name a few:
Is it a system, submodule, or component design?
Is it a green or a brownfield project?
Is the stakeholder experienced enough to know which information matters and which doesn't from the IT project perspecitive?
Does the architect / system designer have previous experience with the same domain?
Does wireframe or mockup exist at project kick-off?
Should the project satisfy special security, legal or governmental regulations?
etc...
In short, yes there can be circumstances where you don't need several iterations, but based on my experiences that's quite rare.
I am using optaplanner with drools score calculation and chained variables.
An additional requirement for my optimization problem is, that some tasks may need more than one worker (e.g., someone has to hold the ladder).
Since this case is not covered by the simple VRP example from the docs, I have to come up with my own implementation (this is were things start to go out of hand :)).
What follows is the description of my idea and a picture of it. My question is, if this kind of chain freezing is possible for OptaPlanner (with multithreading).
If yes, where can I find resources for this?
If not, what are other possibilities to cover team building processes?
Idea:
Two separate workers complete their first tasks. After that, a task requires a team of two. Both suppliers build a team (a team object will inherit from the worker and is also an anchor). As soon as they build a team, they get assigned to blocking tasks (on their initial chains).
Blocking tasks have the same start and duration as the team task. When the team task is completed, the initial chains unfreeze, and the workers continue working on their own again.
!! Not shown in the picture: A team chain needs to be frozen after the team breaks up.
I hope that could explain what I am trying to do.
Best,
David
At my enterprise, we utilize Problem Management to eliminate recurring incidents of course - but how do we organize efforts to eliminate recurring requests?
We are trying to minimize debt by shifting some work to cheaper teams or even outside of IT, consider changing the framework of our applications in order save money in the long run by adding a feature to let the users update things on their own, or even weigh the pros and cons of building out automation to replace manual labor. It would be great if we could tie all of the Service Request or Catalog Tasks together similar to a Problem record - and provide a place for us to organize our efforts or progress made.
Does anyone have any solutions to this? How do you organize your requests?
One solution was to just use Problem and classify them differently - but the cons are that Problem doesn't include Requests in ITIL. Another idea was to build another module that functioned similarly to Problem, but had its own fields and name. We would love to organize this directly in ServiceNow - and would like to have more functionality that PA Dashboards can provide.
Thank you in advance!
The orchestration plugin/module comes with an ROI app which helps you calculate and report on the amount of time/man hours/dollars you are saving with your automation efforts. It basically just tracks tasks and assigns a monetary value based on the salary or wage of the performer that usually executes the task.
Requirement Gathering
a) For the initial state of the project, identify ONE method of information gathering (investigation or requirement gathering) that you would use for this system. Discuss the benefits and setbacks method chosen. You are advised to use different methods among group members.
b) Explain the conduct of the investigation method including how it will be carried-out, target users, location, etc. Create a set of questions that you can use for your investigation. Display the questions only related the system development project.
System: Fast Speed Maths Center
Method of Information Gathering: Direct and Indirect Observation
I'm completely out of idea how to start, what to write inside the documentation, and what's the format.
a) Benefits of using OBSERVATION as method of information gathering.
exp: Very direct method for collecting data or information – best for the study of human behavior.
b) Visit any maths center, observe what are the people are doing, and set questions that you can use throughout the observation.
I am evaluating OptaPlanner for a planning problem I have. I have seen several responses to this topic, but nothing quite like I am looking for.
I am looking for the capability to extend the problem on the fly; that is, as the planner is solving a problem.
For example, in the CloudComputing example, I would like to be able to add computers on the fly (to a point) while the problem is being solved. The easiest case is that the problem is initially over-constrained and to resolve this I would like to be able to add computers, and then replan.
Or, I would like to be able to add a lecture, or a lecturer in one of the scheduling problems, etc.
It seems like the OptaPlanner requires a static number of entities / variables at solve time.
Any pointers would be appreciated.
Take a look at the Real-time planning section of the OptaPlanner User Guide.
You could also look at the Travelling Salesman Problem example in optaplanner-examples. Specifically, look at the org.optaplanner.examples.tsp.swingui.TspPanel class and traverse down from there. It's a pretty standard implementation of real-time planning AFAIK. I can also recommend to run the TSP example first to "see" how it works.