Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I googled the above question in many forms and I could not find any comprehensible answer. Can someone give a real life example that explains the difference between a business process and a workflow ? and how each one is connected to activities.
This diagram was supposed to help but to be honest, it confused me even more.
Questions like this aren't the core purpose of Stack Overflow, so probably you'll get a few flags. But I'll try to give a short answer.
Like many other notions in computing, these two terms, business process and workflow, aren't precisely defined, at least not in a way that is generally understood and accepted. So each author, tool vendor, and the like, use them at their pleasure. For most practical cases, they are interchangeable. BPMN, for example, has "business process" in its name, but many "workflow" engines do nothing else than implement BPMN.
A diagram like the one you got isn't meaningful without a clear explanation of the meaning of its constructs. That's the duty of its author and can't be done by you or me without knowing his intentions.
If anything, the term "workflow" could be more specific than "business process". The workflow means the concrete sequence of actions, like "customer fills order, then vendor calculates delivery data, then warehouse personell fetches products,...". Business process can, depending on the context, also be used for more abstract ideas, like "product design, customer acquisition, order processing" that are not directly related in the everyday work organization.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
The ThoughtWorks Technology Radar July 2014 mentions under Techniques / Trial a new trend called REST without PUT. They explain it as:
In the last radar we talked about Capturing Explicit
Domain Events, putting emphasis on recording the
business-meaningful events that have triggered state
transitions instead of just CRUD’ing entities. REST
interfaces commonly use PUT to update resource state,
however it’s often better to POST to record a new event
resource which captures intent. REST without PUT has a
side-benefit of separating command and query interfaces
and forces consumers to allow for eventual consistency.
Are there any additional resources where one can read about this? Is the term REST without PUT an idea made up by ThoughtWorks, or is this something academic, or …?
Any hints on this?
IMHO they are saying about that one should stop looking behind on CRUD operations and focus on state-transitions. Then you map set of transitions to specific events. One of them is used to update entity. How it would be updated and what would be updated is decided on context of event. One need to POST event of updating instead of PUT update.
BTW that solves one problem with using pure HTML in REST - HTML doesn't allow to trigger PUT or DELETE without JavaScript.
REST without PUT isn't standard; as you guessed, this is just ThoughtWorks thing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have recently inherited a PLC project. We are using Automation Direct PLCs and using the C-more software for writing ladder logic.
C-more allows me to add rungs for "Execute on every scan", "Execute when called", etc.
It also allows me to break out separate sections under each of these headings to attempt some organization.
Are there some agreed upon best practices for structuring ladder logic programs? I'm trying to bring some sanity to the development process.
Document as you go. Logic, elements, memory map, etc. Document for "the other person", even if that person is YOU. PLCs and their programs tend to have a LONG life, so you will be glad 1 year, 5 years or even 20 years down the road when you have to tweak/debug that PLC. You'll be glad you explained things in a little more detail by documenting it for "the other person".
Do NOT wait until "the end" to document. Yes, that implies that you need to keep the documentation up-to-date.
There are no established norms in the PLC programming realm, I've been developing, commissioning, maintaining (and reverse-engineering) PLC programs for 26 years. Many organizations develop in-house standards, but there are no accepted industry-wide standards. However, a method I gleaned from an old pro dictates placing decision-making rungs first (evaluating conditions and setting flags), making control decisions in the next segment, turning outputs on/off in the next section, and monitoring performance/upset conditions in the last.
It's based on how older machines evaluated I/O and handled ladder execution. The advent of ladder 'sub-routines' has helped enormously; I generally treat each motor as a 'sub-system' element and assign its' own sub-routine.
Hope this helps!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Why adopt the UP process over others? What are the relative advantages? I know that it is closely coupled with UML but clearly this cannot be the only advantage? Why choose this approach over others?
I think it really depends against what process/methodology you compare. Without details, only general characteristics of UP can be mentioned.
It is iterative incremental methodology with well described roles and activities, using modeling techniques in object oriented analysis and design. It is vertically (time) divided in phases and those in iterations and horizontally into groups of activities concerning different aspects of software development, such as requirements, analysis, design, testing deployment etc...
Although we are not practitioners of the full UP processes, we use it frequently to see what type of products we need and which roles will have the responsibility to perform the activities for that product. We like it, because it details the various aspects from design until the deployment phase and comes with various templates, guidelines and processes which help out in the development life-cycle.
Take a look at : http://epf.eclipse.org/wikis/openup/
As we are a team where members can play different roles depending the projects, we simply navigate to the role, and check what products are needed for the project at hand. Depending the weight/complexity of the project we will choose the products that will help us in our daily duties. UML is an asset which we highly depend upon and comes as a benefit within OpenUP (or other UP incarnations).
I am certified in RUP and a Scrum Master. Most teams find that no process "off the shelf" is a perfect fit. That being said, the Unified Process focuses on driving risk out of a project early. However, I have seen many implementations where UP introduces a level of risk simply by being overly complex. Depending on the nature of the project, organizational structure, and other factors such as compliance and scale, UP offers a set of practices that can be easily tailored.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've recently checked out some reviews of potential employers on sites like JobVent, Telonu, and Glassdoor. The reviews tend to skew negative as might be expected, so I'm wondering how useful they are for job expectations and a metric of morale in the company?
What I've seen in a couple different interviews seems to be very different than what I'm reading online.
If you checked out a company online before taking a job with a fair number of negative reviews, how did it work out for you?
(If it makes a difference, remember to log out to answer anonymously).
The problem with (publicly-)anonymous reviews on the internet is that they are particularly appealing to those with an ax to grind.
I think they are useful for learning about specific issues (e.g., lots of reviews mentioning long work hours or management pressure) but not for any actual numeric values.
In addition, smaller companies rarely have reviews, while larger corporations have so many subgroups, divisions, and sites that the likelihood of the review applying to your position is minimal.
If you want the inside scoop, you probably need to talk to somebody who worked there (not just interviewed). If it's a big enough company, Facebook or LinkedIn may be your best resource to find such a person as you can search for alumni of your alma mater, etc.
I usually do this sort of thing as part of the interview process - online reviews can be skewed in that the employer might add false positive reviews, and knocked-back applicants will add false-negatives. If I want to see if I'm going to fit in at a company, I do this during the interview. I ask questions (not just of the person interviewing me) in order to get a feel for how sociable / happy / on-edge the other employees are.
I was surprised at how useful it was to ask the interviewers (fellow engineers) what they'd change about the company. It was like opening a release valve... I got very honest answers that really reflected the frustrations they felt - but I could also tell that the source of the frustration was a deep investment in the success of the company.
The problem with review sites like those is that if your company is small, it won't be on there, and if it's large, the complaints aired may not be relevant to the specific group you're interviewing with.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've been working on a small iPhone app that displays web content using the devices GPS context. I am hoping to list this application in the AppStore for free.
If I list the application under my name, does this create any considerable liability considerations?
Thanks in advance,
Ben
This is one of those questions that really belongs on a forum for IP lawyers. I'm not a lawyer, so this is somewhat speculative and should not be taken as legal advice.
A good rule of thumb is that anything you put in the public domain can open you up to legal liability. Whether you put your name on an application or not is irrelevant to whether or not you can be sued.
The open source people often include some boilerplate that amounts to "No express or implied warranty on this application, not even a promise that it will work and not brick your phone." How effective this boilerplate is would need a lawyer's perspective.
You appear to be in the USA, so the answer is "of course it does". And listing it in some other way also does. Anything you do, anywhere, at any time, that affects anyone in any way might well be taken as grounds for a lawsuit. If you want specific legal advice you should be talking to a lawyer.
IANAL, either. But if you give something away for free, something earnestly intended to help its users - and if you explain what it is, and whatever risks you're aware of - I don't think you have much to worry about. Certainly, you shouldn't. I say, do your best to make it good, safe, and all that, and set it free.