I am in stage of getting the export license for my company product, which needs information of all the components/products involved in the implementation of my company product. Regarding Commstudio ActiveX product, my questions are:
What is the country of origin for this product?
Does this product contain any encryption?
Is the product subject to EAR (export administration regulation) or not, if product is USA based? Please explain.
What is the ECCN/Export License number for the above mentioned product?
The most important among all is the question number 1 and 4. I already searched the web, and also written an email to Commstudio personnel, but no success yet.
This is something you really need to contact the manufacturer about directly to make sure you get an accurate answer. From their website it looks like they are US based: http://www.commstudio.com/about/contact
Related
I have a question for a project I am working on. I am working on a RoR project in which a site is selling a single type of item, a book. The person I am creating this for does not want to deal with users creating user account to check out as the sales season is very short for this product, the purchases are done once per year, and the site only sells a single item.
I am wondering if there is something wrong with the implementation I am thinking of. What I was envisioning was a single database class called Orders. visitors to the site would simple fill out an order form with payment details through stripe and click submit. If they payment clears, the order with all the Orders information would be persisted to the DB. If the payment fails then it is not persisted and the relevant error information is displayed in using flash.
I suppose the meat of my question is; is there anything inherently 'wrong' about implementing this model without a users class and just having visitors to the site place orders?
I am a fairly new developer and this is my first big project so any feedback is appreciated!
If your requirements say that it is okay, then it is okay, if your requirements say it is not okay, then it is not okay.
There's not more to say, since only you know what your requirements are.
I am working on a project where I need to capture one time payments from an account. For a bit of background: The account has many users, where users are part of teams as team_members. I have another model we can call projects where teams are affixed to the project. It is on these individual projects that I would like to have a checkout button. The price for this one time payment should be calculated based on the number of individuals in a team, that are part of this project.
My issue is that I am not 100% sure how to achieve this for one time payments in stripe. Should I set this up alike that if I were to sell an individual item? Product (with name, description and price) and an Order to affix to the user?
I've built subscriptions plans in Stripe before, but have never really used one time payments. Any guidance on setup here would be really great.
Small Edit:
When a project is created, a team is selected. That team size is known to the project.
If I have 3 tiers for pricing:
1-5 people in a team is $x
6-20 people in a team is $y
21+ people in a team is $z
How would I go about invoking the correct tier based on the team size for the project?
If you want to keep users on your application while paying, following the web payment example is what you'll want to do. You would provide the amount when creating the PaymentIntent.
You should calculate the amount you want to charge in your own business logic. Once you've got that number, there are several ways you can collect one-time payments with Stripe.
If you want to offer the most flexibility for supported payment methods with the lowest amount of integration effort, Checkout would be a great option. You would supply the amount and a description with the line items while creating the checkout session.
If you want to keep users on your application while paying, following the web payment example is what you'll want to do. You would provide the amount when creating the PaymentIntent.
I'm in the process of creating various archimate models for my organization. We offer financial services. Customers can do most of the things they require using the online portal and the mobile app.
But we also have branch offices where customers can go to get personal attention. They can get personal advice, they can ask representatives for operational tasks, or they can go to a public workstation there and do it themselves using the online portal, potentially with some assistance.
How should I model such a branch office in Archimate? Is it an Actor? Or a Business Service? Or a Business Interface? Or maybe a Product? Or just a Location? It's also a thing that's designed around a specific concept, and we have different concepts, each with a unique setup and capabilities.
You can compare such a branch office with a retail shop, or a post office. It's more than an internal element, because this is a point of contact with your customer. But what kind of element best describes it?
You can use different type of elements to model a branch office:
If you use physical elements, the branch can be a "Facility".
But probably it fits more with a "Location" that can aggregate "Resources" (Strategy Elements) o "Business Roles" that can realize "Business Services".
Consider this image, the customer is served various services (like personal advice) at (or aggregated in) a location assigned to the physical facility. Hope this answers your doubt.
I have the following specification:
Scenario: Retrieve customer license document
Given I have a customer with no license
When I retrieve the license document
Then the license document should not be retrieved
In this scenario the When and Then step definition are more of less the same. What I want to specify with this scenario is that it's not possible to retrieve a license document when the customer has no license.
When I Retrieve the license document implies that the retrieving of the license is possible.
Does anyone have a solution to rewrite this scenario?
In such cases, the when clause is redundent
Scenario: Retrieve customer license document
Given I have a customer with no license
When I retrieve the license document
Then the license document should not be retrieved
Put the then caluse's codebehind implemenyation in try catch. In catch, post a success. In try block, at the end raise an exception.
There is no hard and fast rule on how do you write the scenarios, there isn't any standard format in gherkin either. But, gherkin is specifically, for having and making non-technical like BA's, stackholders, non technical managers understand, what the test is really about. The more precise you use the sentences, the more understandable and meaningful it is.
If you are not going to write the steps in a understandable way, there is no need to implement gherkin at all. You may just code it in ruby or Java and let the BA's etc.. understand the code on their own.
In your scenario, Using When in the third step, makes more sense than then.
When is precisely to describe the key action the user/Program
performs.
The purpose of Then steps is to observe outcomes.
Scenario: Retrieve customer license document
Given I have a customer with no license
`When` I retrieve the license document
Then the license document should not be retrieved
So you have a scenario like this:
Scenario: Retrieve customer license document
Given I have a customer with no license
When I retrieve the license document
Then the license document should not be retrieved
BDD is all about communication between the development team and the business. What would the business describe the behaviours of the system to be?
Would they say something more like this?:
Scenario: Customer has no license
Given Carl the Customer has no license
When Bernadette the Business User attempts to retrieve Carl the Customers licence document
Then Bernadette the Business User should see no license document for this customer
Scenario: Verify that license document should not be retrieve when customer has no license
Given I have a customer with no license -- Given explains what you have
When I retrieve the license document -- When explains what you trying to do
Then verify that the license document should not be retrieved --- it is the final result of scenario
Reading online material (e.g. Fowler, Gerard), it seems that Specification By Example stories should not be complete specifications of functionality.
Question 1: How does one starting off with SBE's decide how comprehensive their stories need to be in terms of describing all of the functionality of a system? I.e. when can I stop writing stories because I have captured enough?
Question 2: In an organisation where test teams verify products against the product documentation, if the stores are not a complete specification, am I correct in thinking that 'other' product documentation needs to contain all the cases that are not covered by the SBE's?
Regarding question 1:
The most important part of developing any system is that the development team has a conversation with the product owner. First find out the crux of the feature which they require. I'll answer this question by working through an example; let us say that the product owner may want a facility to login to their new website. This requirement could be written as:
In order to gain access to the website's facilities
As a user
I want to be able to login to the website
(Note that I'm using the Gherkin domain specific language for writing the scenarios and features in this answer)
With the product owner's key requirement specified, you should now discuss with them how you think this feature should be implemeneted from a users perspective (keep it high-level, don't use technical jargon, discuss with the business to find out what they want). So the first "happy path" scenario you might identify could be:
Given a user is on the login screen
When they submit valid login credentials
Then they gain access to the main website
After further discussion with the product owner they tell you that as the website contains extremely sensitive information, and that any failed log-in attempts should be reported to a system administrator. This would result in another scenario:
Given a user is on the login screen
When they submit invalid login credentials
Then the system administrator is informed of the failed log-in attempt
And the user is informed that their login attempt failed
At this point the product owner might say that these are the only scenarios they want for logging into the system. So from the development teams perspective no more investigation would need to be done regarding this feature (so you wouldn't need to write any more user stories). Sure, at a later point in the projects development, the product owner might also tell you that they'd like to inform a user when they last logged into their site before reaching the main website, but you'd only need to worry about this when they ask for it.
Regarding question 2:
The organisation should be verifying the products against "living" documentation e.g. using Cucumber(for example) which generates tests from the scenarios detailed above.
Also as I said in the answer to question 1, you should identify "just enough" of the scenarios/use cases to satisfy the product owner. What the product owner asks for is the complete specification. Don't try and second guess what the product owner might want because this may result in be a classic case of YAGNI.