I know precisely what a "third-party library" is, so I assume that the "third-party" in this case simply is an arbitrary person or company other than the developer?
Does it have to do with "first person", "second person", and "third person" grammatical points of view?
The fact that there is a "third party" suggests that there is a "first party" and a "second party" as well. Are those terms well defined?
(I'm not a native english speaker.)
If you are developing software for a client, then there is a contract between you/your company, and the client/their company. These are the two parties to the contract. Anyone else, not bound by the contract, is a third party. It's used wherever a contract exists between two parties to mean anyone not bound by the contract.
There is no fixed meaning to which of the two parties is 'first' and which 'second', usually you will think you're the first party, and the client the second, whereas the client will think they are the first party and you the second, in a similar fashion to first, second and third person I/he/they.
These terms are well defined in English when talking about grammar (English grammar or another language's).
First person corresponds to the
pronouns "I" and "we"; "me" and "us" (so a book written in the first person is a story told by the central character - "I did this" as opposed to "Smith did this").
Second person corresponds to the
pronoun "you".
Third person
corresponds to the pronouns" he",
"she", "it" and "they"; "him", "her"
and "them".
So "third party" just means not you or me, but them.
1st party = I
2nd party = you
3rd party = he/she (i.e. someone external to the conversation)
Let's take Iphone for example.
Apple by its hardware and software are first party.
End user like me and you are the second party .
the third party is the person who enter this relation like an app developer
that effect me and apple .
Note: the first and second party can be swapped .
First party: developers
Second party: end users (I think)
Third party: Libraries etc provided
by someone else other than the
developers. PDFSharp will be
considered 3rd party.
I don't think first and second party are used that much, if at all, in programming. If someone started talking about first and second parties at work, I would wonder what they meant. However, "third party" is much more common and familiar.
"Third party software" is a common term. I've never heard of "first party software", or "second party software".
PS: I'm a native English speaker in the UK.
It is related to the ISO/IEC 17024 Conformity Assessment.
1st party:
Is performed by the person or organization that provides the object
2nd party:
Is performed by a person or organization that has a user interest in the object
3rd party:
Is performed by a person or body that is independent of the person or organization that provides the object, and of the user interests in that object
Conclusion:
First party is the person self-attesting that he or she is competent.
Second party is someone related to the person (trainer/instructor/employer) declaring that the person is competent.
Third party would require an entirely independent party to declare the person competent.
My Source: http://www.proftesting.com/blog/2016/09/28/first-second-and-third-party/
It's a term that's often used in Windows-centric development: the first and second parties are me (or you), and Microsoft; and the third party is anyone else:
Sometimes it means the customer or end user (e.g. "if we get a 'redistributable' from Microsoft, that means that we can redistribute it to 'third parties'")
More often, it means a non-Microsoft vendor of programming tools or libraries, which I'm using (for example, "NUnit and Reflector are both example of 'third-party' tools").
Oxford Dictionnary
third party
noun
a person or group besides the two primarily involved in a situation, esp. a dispute.
• a political party organized as an alternative to the major parties in a two-party system.
adjective [attrib.]
of or relating to a person or group besides the two primarily involved in a situation : third-party suppliers.
I think of it as from where the code comes from, so when it comes to libraries and development tools I'd say that the first and second parties are the developer and the producer of the development tool. So as a .Net developer the parties are me and Microsoft, since I write code using Microsofts framework and controls and I might also then user third party code/controls.
1st party is Developer, 2nd party is software user
It's context driven though. This situation also applies.
From a development perspective:
I'm developing an app for my company for internal use (first Party)
Most of the "assets" that I'm using for the app are from Microsoft (second party)
But I'm also using this database library from this other company (third party)
First and Second remain interchangeable depending on perspective. The customer isn't even on this chart but that's partially because that's an entirely different relationship with it's own rules.
Be careful when talking about legal contracts because while they do often use the term third party as we're discussing, there is also the practice of identifying pe4ople as"the party of the first part A, the party of the second part B, the party of the Third part C, ... , the party of the nth part ...
which serves only to list a bunch of people without specifying a relationship. And it can also be the parties of the first part a,b,c and the parties of the second part x,y,z, ...
The first party is the developer of the website, program, or game. Like Microsoft or Google.
The second party is the client, the viewer of the developer's work.
The third party is an external source of media.
Related
I have recently tried to review the Chinese -> English system. According to https://blogs.msdn.microsoft.com/translation/2017/11/15/microsoft-translator-accelerates-use-of-neural-networks-across-its-offerings/ , those systems were already switched to NMT models. There is also statement, that user can still use the statistical system when setting category to "SMT".
However the https://blogs.msdn.microsoft.com/translation/2016/01/27/new-microsoft-translator-customization-features-help-unleash-the-power-of-artificial-intelligence-for-everyone/ mentions there were actually three standard categories available for SMT engines: General(default), TECH, SPEECH.
Could you please explain which domain is offered by the SMT category now? And for how long it will be supported on your side?
Thanks
We are working on customizaton using a neural network decoder. Currently, the Microsoft Translator Hub has 3 Category IDs for SMT and they are general, tech and speech.
With content that is not narrowly confined to your domain, you may find it to be better using category=generalnn than your current customization.
Chinese is using the NMT system so using Category=generalnn would result in the same translation when calling the service using the Microsoft Translator Text API.
The second article is addressing Customization where you can create your own custom translation system or dictionary tuned to your domain, style and terminology. If you're interested in customization (SMT at this time), there are categories associated with using the Translator Text API and the Microsoft Translator Hub. The category identifies the domain for the project you create using the Hub. Two of the categories are Tech and Speech.
See the Microsoft Translator Hub User Guide to learn more about the Hub.
The tech category will produce different results only when translating FROM English to other languages. In the case of English>Chinese, with my sample sentence "My computer doesn't boot up.", it does. For Chinese>English, specifying "tech" will fall back to the default, which is neural in the case of Chinese<>English. "speech" generates the same results as "generalnn" in all cases.
It is generally true, including for Hub categories, that a category that is valid in one language pair is valid in all language pairs. The API will fail with an "invalid category" error only if that category doesn't exist at all. The reason for this design is so that you can build your custom systems out language by language, over time, while still allowing the user to choose between all available languages, at the cost of, maybe, occasionally suboptimal domain vocabulary in an as of yet uncustomized language pair.
The API does not return to you whether a customized system was used or not. A trick to get that feature anyway is to watermark your custom system using a dictionary entry. Make a dictionary entry "_mywatermark" that translates to "CustomSystem180309_1700_en_ru" for instance, and then you can test anytime, in any application, whether you are getting your custom system or not.
We develop a Win32 program (=host) which allows 3rd party to write plug-ins. As some plug-ins contains valuable piece of code (for example, high quality video scalar), the 3rd parties want to limit their plug-in to work only with our host program.
Our idea is to use Microsoft Authenticode technology to sign the host. Then, the 3rd parties are asked to implement the following algorithms to check the host. (The 3rd parties are expected to do sufficient code obfuscation for the algorithm).
Use WinVerifyTrust() API to verify the certificate of the host is valid (= Not revoked, not tampered, etc).
Verify the certificate that the subject is our company.
The question is about step (2). The 3rd parties cannot simply check thumb print or serial number because the digital certificate of the host will be renewed after the certificate expiration date.
My idea is to check parts of subject's distinguished name, specifically "country (C)" and "common name (CN)", assuming that there is no company name confliction in the United States. We shouldn't check other attributes such as state and city because our company might move - in fact, we have moved from one city to another just a year ago.
Question: Is it good way to accomplish the goal?
While the scheme is workable, it's possible to relatively easily circumvent protection by just patching plugins so that they ignore the signature or skip signature verification altogether.
What is even more important, - if you plan to have multiple plugins/vendors, you would have hard time ensuring that all vendors obfuscate validation code right.
Then, I'd say that it can be against plugin vendor's interest to limit their plugin to your application only - if they want bigger market, they might want to have the same plugin run on wider scope of hosts.
We have a number of AS/Flex components that we've built over time and improved upon. They've been turned into components so they can be reused in different projects and save us time. So you can think of them as part of an in-house framework of sorts.
We're now realizing that it doesn't make sense to release the source code for these components to the various clients as part of the project, because technically this code isn't really owned by the clients.
So my question
When a client comes to you, how do you explain to them that you can't give them the full source code for those components. The client doesn't understand the difference, he just expects you to give them all the code for the site that he paid you to do. He doesn't understand that this code has taken you a lot longer to write than what he's paying for his site. But since he doesn't understand, he would get turned off and thinks you're ripping him off or something.
How do you handle this situation? What do you tell clients upfront? Do you advertise it on your site from the very beginning? How do you handle their objections so they still hire you?
As a side question, how often do you give AS and Flex source code to your clients? In the case when the code doesn't have any in-house components that you reuse in several projects, and in the case when it does have in-house components.
I'd also like to hear from people who've worked at creative agencies since they're most likely have run into that issue already.
I'd explain to my client how the world works. I'd use examples, analogies and metaphors.
This isn't a software-development issue, this applies to all products. Some things are sold as black-box, and some things are sold as a clear-box containing black-boxes inside it.
Lets say you wish to buy a house. You pay the engineer and the architect for their work, and you gain the documents they produce. These documents contain information that relies on other pieces of information, which you do not gain. For example, the engineer may use huge steel bars in his plans. The engineer's specifications determine the qualities that each steel bar must have, but they do not specify how the steel bars are created. Buying house plans doesn't buy you the plans for creating the house's building blocks.
With softwre it is pretty much the same: you don't get the source code for the .NET framework when you buy a .NET application "with sourcecode included". What you do get is the .NET documentation, specifying how to work with the framework (and not specifying how the framework does what it does).
The amount of examples is actually endless, because - as stated above - this is the way the world works.
Build your own analogies to fit your scenario. Explain to your customer where the infrastructure ends and his owned solution begins.
quoo is right about the need to specify these in the contract. The contract is the legal backbone of the deal. But i'd like to emphasise the fact that pointing at the contract should be a last resort. If you can give your client a reasonable explanation such that lets the client understand why things are the way they are, you won't need to wave the contract (which speficies only the way things are, without the motivation, explanation, etc.).
I'm not a business person, but generally these things are specified in the contract. If your contract stipulates that you provide the client with the source code at the end of the project, then at the very least, you should be providing them with swcs of your components so they can recompile the code if necessary. If you don't want to share your code with the client, then that too is something that you'll need to specify up front.
Just explain that you can not provide the source for external libraries that you used on his project to make the bid cheaper for him. He would not expect the source from a 3rd party vendor that you used in his project, just try to explain this is the exact same situation.
Intellectual property issues should be covered upfront as part of the contract. I'm not a lawyer but common practise is to specify:
Which components are provided by third parties and refer to their licensing terms
Which code will be produced as part of the contract.
Whether you license or sell various intellectual property rights.
Licensing terms.
Intellectual Property laws` are complex and diverse, they differ from country to country. Depending where you're and where your customer is the licensing terms might need to change. As an example, reverse engineering viewed differently in different jurisdictions.
Apart from third-party components and software bits you don't want to sell, nor give an exclusive license for you'd probably want to be able to exhibit and distribute the works as part of your company portfolio. This latter activity would also need to be covered within the contract.
Having a well written contract prepared up front will save a lot of misunderstanding and unnecessary negotiations. You'd probably need just one template you could use for all your customers. So my advice really is "talk to a lawyer".
Your contract should make clear that components developed by you are licensed to the client for use as part of the project and only the project(s) you did for them. Of course, you'll need to determine the exact language for yourself and the situation, but if you're repeatedly using these components in your projects, you really ought to have some sort of boilerplate for just this situation.
What is another good word for Business Logic?
Software might also run in civil service offices or for hobbyists, so I never felt that comfortable with using that term in certain modules and documentation.
App Logic is too specific as well, because logic modules might also be used in services.
You might be able to get away with Domain Logic?
Orchestration Layer or just Orchestration.
How about Core logic? It's exactly what you are referring to with business logic anyway - the core logic of your app
Workflow / Bussiness workflow / Domain modeling / Bussiness Process
Good question! I want to give 2, admittedly quite opinionated, answers.
The word business isn't actually that bad, if you think about the original meaning. Business comes from the work busy. It doesn't actually have anything to do economics, finance, professions or money. This is evident form expressions like "mind your own business", "let's get down to business" or "funny business". So "business" is simply the thing which keeps us, or an application, "busy". However, I do agree that the way the word is used currently often associated with money, so I understand why you would want another word.
So to offer an alternative, I like to use "controller". This comes from the "middle layer" of a model-view-cotroller artchitecture. MVC is designed for GUI applications, but IMO the concept can be extended also into other areas and types of applications.
Let's get wild:
Features
API
Functionality
BL
Modules
Core
Actions
Commands
all of them are way too broad or not equivalent to "business logic", but you still might want to name a module like this :)
A little background: I have the opportunity to present the idea of a public API to the management of a large car sharing company in my country. Currently, the only options to book a car are a very slow web interface and a hard to reach call center. So I'm excited of the possiblity of writing my own search interface, integrating this functionality into other products and applications etc.
The problem: Due to the special nature of this company, I'll first have to get my proposal trough a comission, which is entirely made up of non-technical and rather conservative people. How do I explain the concept of an API to such an audience?
Don't explain technical details like an API. State the business problem and your solution to the business problem - and how it would impact their bottom line.
For years, sales people have based pitches on two things: Features and Benefit. Each feature should have an associated benefit (to somebody, and preferably everybody). In this case, you're apparently planning to break what's basically a monolithic application into (at least) two pieces: a front end and a back end. The obvious benefits are that 1) each works independently, so development of each is easier. 2) different people can develop the different pieces, 3) it's easier to increase capacity by simply buying more hardware.
Though you haven't said it explicitly, I'd guess one intent is to publicly document the API. This allows outside developers to take over (at least some) development of the front-end code (often for free, no less) while you retain control over the parts that are crucial to your business process. You can more easily [allow others to] add new front-end code to address new market segments while retaining security/certainty that the underlying business process won't be disturbed in the process.
HardCode's answer is correct in that you should really should concentrate on the business issues and benefits.
However, if you really feel you need to explain something you could use the medical receptionist analogue.
A medical practice has it's own patient database and appointment scheduling system used by it's admin and medical staff. This might be pretty complex internally.
However when you want to book an appointment as a patient you talk to the receptionist with a simple set of commands - 'I want an appointment', 'I want to see doctor X', 'I feel sick' and they interface to their systems based on your medical history, the symptoms presented and resource availability to give you an appointment - '4:30pm tomorrow' - in simple language.
So, roughly speaking using the receptionist is analogous to an exterior program using an API. It allows you to interact with a complex system to get the information you need without having to deal with the internal complexities.
They'll be able to understand the benefit of having a mobile phone app that can interact with the booking system, and an API is a necessary component of that. The second benefit of the API being public is that you won't necessarily have to write that app, someone else will be able to (whether or not they actually do is another question, of course).
You should explain which use cases will be improved by your project proposal. An what benefits they can expect, like customer satisfaction.