vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Check out the [Twelve-Factor App](https://12factor.net/), a language-neutral methodology for considering how to develop your app across 12 factors, summarized as follows.



1. Code base: Use a single code base in a version control system for your deployments. When you pull an image for your container deployment, specify a tested image tag instead of using latest.
2. Dependencies: Explicitly declare and isolate external dependencies.
3. Configuration: Store deployment-specific configuration in environment variables, not in the code.
4. Backing services: Treat backing services, such as data stores or message queues, as attached or replaceable resources.
5. App stages: Build in distinct stages such as build, release, run, with strict separate among them.
6. Processes: Run as one or more stateless processes that share nothing and use [persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-plan) for saving data.
7. Port binding: Port bindings are self-contained and provide a service endpoint on well-defined host and port.
8. Concurrency: Manage and scale your app through process instances such as replicas and horizontal scaling. Set resource requests and limits for your deployments. Note that Calico network policies can't limit bandwidth.
9. Disposability: Design your app to be disposable, with minimal startup, graceful shutdown, and toleration for abrupt process terminations. Remember, containers, pods, and even worker nodes are meant to be disposable, so plan your app accordingly.
10. Dev-to-prod parity: Set up a [continuous integration](https://www.ibm.com/garage/method/practices/code/practice_continuous_integration) and [continuous delivery](https://www.ibm.com/garage/method/practices/deliver/practice_continuous_delivery) pipeline for your app, with minimal difference between the app in development and the app in prod.
11. Logs: Treat logs as event streams: the outer or hosting environment processes and routes log files.
What makes a good Cloud Foundry app? 

IBM® Cloud Foundry is deprecated and no longer supported as of 1 June 2023. For more information, see the [deprecation details](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecationdep_details).

Modern cloud apps, including those using Cloud Foundry, follow key development methodologies: cloud platforms, agile development, DevOps, microservices, and continuous delivery.

To follow these methodologies, you want to have a Platform-as-a-Service (PaaS) model. Although not required, PaaS makes things a lot easier. Most cloud customers are using or start out with infrastructure-as-a-service (IaaS), which helps abstract their apps from the underlying hardware. However, PaaS adds an extra layer to abstract the underlying OS, so you can focus entirely on the business logic of your app and not worry about managing the platform.

There are two major concepts that come into play: "cloud-native" apps and "12 Factor apps".



 Cloud-Native 

A "cloud-native" app is defined by the Cloud Native Computing Foundation.



* “Cloud-native technologies empower organizations to build and run scalable apps in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
* These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably, with minimal toil.”



So a "cloud-native" app isn't just an "app". It's a set of processes and best practices that also go along with it. The transformation of the development processes is critical. The "development ecosystem" is quickly learning the best ways to deliver software, and that is an important part of the latest app creation process.

So let's overview the important points about cloud-native apps:
Check out the [Twelve-Factor App](https://12factor.net/), a language-neutral methodology for considering how to develop your app across 12 factors, summarized as follows.



1. Code base: Use a single code base in a version control system for your deployments. When you pull an image for your container deployment, specify a tested image tag instead of using latest.
2. Dependencies: Explicitly declare and isolate external dependencies.
3. Configuration: Store deployment-specific configuration in environment variables, not in the code.
4. Backing services: Treat backing services, such as data stores or message queues, as attached or replaceable resources.
5. App stages: Build in distinct stages such as build, release, run, with strict separate among them.
6. Processes: Run as one or more stateless processes that share nothing and use [persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage-plan) for saving data.
7. Port binding: Port bindings are self-contained and provide a service endpoint on well-defined host and port.
8. Concurrency: Manage and scale your app through process instances such as replicas and horizontal scaling. Set resource requests and limits for your deployments. Note that Calico network policies can't limit bandwidth. Instead, consider [Istio](https://cloud.ibm.com/docs/containers?topic=containers-istio).
9. Disposability: Design your app to be disposable, with minimal startup, graceful shutdown, and toleration for abrupt process terminations. Remember, containers, pods, and even worker nodes are meant to be disposable, so plan your app accordingly.
10.
Select the service that is required to use your product.
3. Select the service access role that is required. The service access role allows access for using the service and performing service API calls.
4. Select the platform access role that is required. The platform access role enables actions to be performed on platform resources, such as creating an instance, connecting instances to apps, and assigning user access.
5. Click Add > Next.









 Defining IAM access by using the CLI 

If you included a catalog manifest file in your repository, the IAM access was automatically imported into the private catalog. If not, you can add new access by using the console. To view the steps, see [Defining IAM access by using the console](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-onboard-custom&interface=uicustom-solution-access-ui).







 Adding deployable architecture details by using the console 

Each variation of a deployable architecture must have at least one architecture diagram. Architecture diagrams must be provided in .svg format and outline the system and relationships, constraints, and boundaries between the components of the deployable architecture.

If your catalog manifest contains architecture diagram information, it was automatically imported during onboarding. If not, complete the following steps to add an architecture diagram:



1. Click Add architecture diagram.
2. Click Add.
3. Enter the URL to your SVG diagram.
4. Add a short caption that describes what architecture is being depicted.
5. Add a longer description that explains in more detail what this architecture helps to achieve and what types of relationships between components are represented.
6. Optional: Click Add if you want to provide more diagrams.
7. Click Update.
8. Review what you added, and click Next.





 Adding highlights 

You can add details that highlight the processes, abilities, and results of the version, or if applicable, the architecture variation. If you have multiple architecture variations, each variation should use the same highlight and then a unique description of how it does or doesn't meet each.
Before you begin 

Attention! The IBM Blockchain Platform Extension for VS Code (VS Code extension) referenced throughout the documentation is an open-source project which is no longer active, and therefore not officially supported by IBM. Refer to the [alternatives to the VS Code extension](https://github.com/IBM-Blockchain/blockchain-vscode-extension/issues/3159).





 Prerequisites 



* Windows 10, Linux, or Mac OS are currently the supported operating systems.
* VS Code [version 1.40 or greater](https://code.visualstudio.com/).
* [Docker version v17.06.2-ce or greater](https://www.docker.com/get-started).
* If you are developing Go smart contracts, you need to install [Go version v1.12 or greater](https://golang.org/dl/). Note that if you are using Fabric v2.x, you will need Go version v1.13 or higher instead.
* If you are developing Node smart contracts, you need to install [Node ^10.15.3 or ^12.15.0 and npm v6.x or greater](https://nodejs.org/en/download/).



Considerations if you are developing Java smart contracts:



* Java 11 is required to execute Java smart contracts.
* Gradle v4.x is used to build Java smart contracts.
* Custom Gradle versions can be used by using a Gradle wrapper.
* Java smart contracts must use fabric-chaincode-shim at v1.4.6 or later (if deploying on a peer that uses a Fabric 1.4.x image; peers that use a Fabric 2.x image do not require a shim), as this version is the first version that includes support for Java 11.
* For an example of a Java smart contract, see the [Basic asset transfer smart contract](https://github.com/hyperledger/fabric-samples/tree/master/asset-transfer-basic/chaincode-java).



If you are using Windows, you also must ensure the following:
Use the workspace file CocoaPods creates for your app to open the project in Xcode.

After installation, open your project workspace. You might get the following warning when building: Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly. This is caused if CocoaPods does not update the Swift version in the Pods project. To fix, select the Pods project and the IBM Cloud® Functions target. Go to Build Settings and change the setting Use Legacy Swift Language Version to no. Alternatively, you can add the following post installation instructions at the end of you Podfile:

post_install do installer
installer.pods_project.targets.each do target
target.build_configurations.each do config
config.build_settings['SWIFT_VERSION'] = '4.0'
end
end
end





 Install mobile SDK with Carthage 

Create a file in the project directory for your app and name it Cartfile. Put the following line in the file:

github "openwhisk/openwhisk-client-swift.git" > 0.3.0 Or latest version

From the command line, type carthage update --platform ios. Carthage downloads and builds the SDK, creates a directory that is called Carthage in the project directory for your app, and puts an OpenWhisk.framework file inside Carthage/build/iOS.

You must then add OpenWhisk.framework file to the embedded frameworks in your Xcode project





 Install mobile SDK from source code 



1. Download the [source code](https://github.com/apache/openwhisk-client-swift).
2. Open the project by using the OpenWhisk.xcodeproj with Xcode. The project contains two schemes: "OpenWhisk" (targeted for iOS) and "OpenWhiskWatch" (targeted for watchOS 2).
3.
MFPPushNotificationListener notificationListener = new MFPPushNotificationListener() {

@Override
public void onReceive (final MFPSimplePushNotification message){
// Handle Push Notification
}
};

push.listen(notificationListener)

// with this

ENPushNotificationListener notificationListener = new ENPushNotificationListener() {

@Override
public void onReceive (final ENSimplePushNotification message){
// Handle Push Notification
}
};

push.listen(notificationListener)
Show more
5. Make changes to the device registration step.



* If you are registering without userID

// Replace the below section

push.registerDevice(new MFPPushResponseListener<String>() {

@Override
public void onSuccess(String response) {
//handle successful device registration here
}

@Override
public void onFailure(MFPPushException ex) {
//handle failure in device registration here
}
});

// with this

push.registerDevice(new ENPushResponseListener<String>() {

@Override
public void onSuccess(String deviceId) {
//handle successful device registration here
}

@Override
public void onFailure(ENPushException ex) {
//handle failure in device registration here
}
});
Show more
* If you are using registerDeviceWithUserId

// Replace the below section

push.registerDeviceWithUserId("userId", new MFPPushResponseListener<String>() {

@Override
public void onSuccess(String response) {
//handle successful device registration here
}

@Override
public void onFailure(MFPPushException ex) {
//handle failure in device registration here
}
Unsupported: Beta versions of ValidatingWebhookConfiguration and MutatingWebhookConfiguration APIs Migrate manifests and API clients to use the admissionregistration.k8s.io/v1 API version, available since Kubernetes version 1.16. For more information, see [Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know](https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/). 
 Unsupported: Beta version of CustomResourceDefinition API Migrate manifests and API clients to use the apiextensions.k8s.io/v1 API version, available since Kubernetes version 1.16. For more information, see [Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know](https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/). 
 Unsupported: Beta version of APIService API Migrate manifests and API clients to use the apiregistration.k8s.io/v1 API version, available since Kubernetes version 1.10. For more information, see [Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know](https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/). 
 Unsupported: Beta version of TokenReview API Migrate manifests and API clients to use the authentication.k8s.io/v1 API version, available since Kubernetes version 1.10. For more information, see [Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know](https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/).
Initializing BMSClient 

BMSCore provides the HTTP infrastructure that the other IBM Cloud® Web and Mobile services client SDKs use to communicate with their corresponding IBM Cloud services.



 Initializing your Android app 

You can either download and import the BMSCore package to your Android Studio project, or use Gradle.



1. Import the Client SDK by adding the following import statement at the beginning of your project file:

import com.ibm.mobilefirstplatform.clientsdk.android.core.api.;
2. Initialize the BMSClient SDK in your Android application by adding the initialization code in the onCreate method of the main activity in your Android app, or in a location that works best for your project.

BMSClient.getInstance().initialize(getApplicationContext(), BMSClient.REGION_US_SOUTH); // Make sure that you point to your region

You must initialize the BMSClient with the bluemixRegion parameter. In the initializer, the bluemixRegion value specifies which IBM Cloud deployment you are using, for example, BMSClient.REGION_US_SOUTH, BMSClient.REGION_UK, or BMSClient.REGION_SYDNEY.







 Initializing your iOS app 

You can use [CocoaPods](https://cocoapods.org) or [Carthage](https://github.com/Carthage/Carthage) to get the BMSCore package.



1. To install BMSCore by using CocoaPods, add the following lines to your Podfile. If your project doesn't have a Podfile yet, use the pod init command.

use_frameworks!

target 'MyApp' do
pod 'BMSCore'
end

Then run the pod install command, and open the generated .xcworkspace file. To update to a newer release of BMSCore, use pod update BMSCore.

For more information about using CocoaPods, see the [CocoaPods Guides](https://guides.cocoapods.org/using/index.html).
2.
use_frameworks!

target 'MyApp' do
pod 'BMSCore'
end

Then run the pod install command, and open the generated .xcworkspace file. To update to a newer release of BMSCore, use pod update BMSCore.

For more information about using CocoaPods, see the [CocoaPods Guides](https://guides.cocoapods.org/using/index.html).
2. To install BMSCore by using Carthage, follow these [instructions](https://github.com/Carthage/Carthagegetting-started).



1. Add the following line to your Cartfile:

github "ibm-bluemix-mobile-services/bms-clientsdk-swift-core"
2. Run the carthage update command.
3. After the build is finished, add BMSCore.framework to your project by following [Step 3](https://github.com/Carthage/Carthagegetting-started) in the Carthage instructions.

For apps that are built with Swift 2.3, use the carthage update --toolchain com.apple.dt.toolchain.Swift_2_3 command. Otherwise, use the carthage update command.



3. Import the BMSCore module.

import BMSCore
4. Initialize the BMSClient class by using the following code.

Place the initialization code in the application(_:didFinishLaunchingWithOptions:) method of your app delegate, or in a location that works best for your project.

BMSClient.sharedInstance.initialize(bluemixRegion: BMSClient.Region.usSouth) // Make sure that you point to your region

You must initialize the BMSClient with the bluemixRegion parameter. In the initializer, the bluemixRegion value specifies which IBM Cloud deployment you're using, for example, BMSClient.Region.usSouth, BMSClient.Region.unitedKingdom, or BMSClient.Region.sydney.







 Initializing your Cordova app 



1.
target '<yourTarget>' do
use_frameworks!
pod 'IBMCloudAppID'
end
4. Install your dependencies from the command line within your project directory.

pod install --repo-update
5. After installation, open the {your app}.xcworkspace file that contains your Xcode project and your linked dependencies
6. Enable keychain sharing in your Xcode project. Navigate to Project Settings > Capabilities > Keychain Sharing and select Enable keychain sharing.
7. Open Project Settings > Info > URL Types, and add a URL Type. Place the following value in both the Identifier and the URL Scheme text boxes.

(PRODUCT_BUNDLE_IDENTIFIER)







 Initializing the SDK 



1. Initialize the client SDK by passing the tenant ID and region parameters to the initialize method.

AppID.sharedInstance.initialize(tenantId: <tenantID>, region: <region>)

A common, though not mandatory, place to put the initialization code is in the application:didFinishLaunchingWithOptions method of the AppDelegate file of your Swift application.
2. Import the App ID SDK to your AppDelegate file.

import IBMCloudAppID
3. Configure your application to process redirects through App ID.

func application(_ application: UIApplication, open url: URL, options :[UIApplication.OpenURLOptionsKey : Any]) -> Bool {
return AppID.sharedInstance.application(application, open: url, options: options)
}









 Accessing protected APIs 

After a successful login flow, you can use your access and identity tokens to invoke protected backend resources that use the SDK or a networking library of your choice.



 With the Swift SDK 



1. Add the following imports to the file in which you want to invoke a protected resource request:

import BMSCore
import IBMCloudAppID
2. Invoke your protected resource
If your app requires either of these capabilities and does not list them in the container or pod securityContext, then the app must be changed to include these capabilities. If these changes are not made, your microservices might fail to start and you might see a permission denied error. Applications developed for OCP already have the necessary changes. 
 Strongswan users If you are using Strongswan in your cluster, then update at least version 2.7.11 of Strongswan before you update your cluster master to Red Hat OpenShift 4.8. In versions of Strongswan earlier than 2.7.11, certain [Strongswan configuration options](https://cloud.ibm.com/docs/openshift?topic=openshift-vpnvpn-setup) do not work with the Red Hat OpenShift 4.8 master.
Check section - [What are the charges to use App Configuration?](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-faqs-usagefaq-ac-charges) to determine what constitutes an API call.

If your pricing plan includes a free allotment of API calls, then you are not charged until the allotment is exceeded. Closely monitor your historical activity and check out [How to view usage metrics for App Configuration?](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-faqs-usagefaq-ac-metrics) Rely on your own domain knowledge, business metrics, and usage forecasts to predict cost.





 Can you give some example pricing scenarios? 



 Pricing Scenario 1: Mobile App with Feature Flags 

Assume you have a mobile app and you want feature flags and targeted segments to roll out features incrementally to different sets of users. Your historical metrics show 200,000 users but only about 50% are active in a month. An average active user opens the app or brings it to the foreground once every day. You expect to roll out a new feature twice per month.

You need the App Configuration Enterprise plan to support both feature flags and segmentation.

For this example, assume an Enterprise plan instance is $500 per month, active entity IDs are $0.01 each, and API calls are $10 per 100,000. NOTE: These prices are assumed for this example only. Current pricing may be different from the amounts shown in the example. See the App Configuration catalog page for current pricing.

App Configuration Enterprise instances: 1 @ $500 per month Active Entity IDs: 200,000 total app instances (users) * 50% active = 100,000 Included Active Entity IDs: 10,000 Net Active Entity IDs: 100,000 - 10,000 = 90,000 @ $0.01 per Active Entity ID = $900
The SDKs enable mobile applications to interact with both the Text to Speech and Speech to Text services. You can use the SDKs to send text to the Text to Speech service and receive an audio response.



* The Watson Swift SDK is available from the [swift-sdk repository](https://github.com/watson-developer-cloud/swift-sdk) in the watson-developer-cloud namespace on GitHub.
* The Watson Speech Android™ SDK is available from the [speech-android-sdk repository](https://github.com/watson-developer-cloud/speech-android-sdk) in the watson-developer-cloud namespace on GitHub.



Both SDKs support authenticating with the speech services by using either your IBM Cloud service credentials or an authentication token. Because the SDKs are beta functionality, they are subject to change in the future.

New Japanese voice: ja-JP_EmiVoice
: The service supports a new language, Japanese. The voice ja-JP_EmiVoice is a Japanese female voice.





 1 July 2015 

The Text to Speech service is now generally available
: The service moved from beta to general availability (GA) on 1 July 2015. The following differences existed between the beta and GA versions of the Text to Speech API. The GA release requires that users upgrade to the new version of the service.

New token-based programming model
: A new programming model supports direct interaction between a client and the service. By using this model, a client can obtain an authentication token for communicating directly with the service. By using the token, the client can bypass the need for a server-side proxy application in IBM Cloud to call the service on its behalf. Tokens are the preferred means for clients to interact with the service.

The service continues to support the old programming model that relied on a server-side proxy to relay communications and data between the client and the service. But the new model is more efficient and provides higher throughput.

New support for the Speech Synthesis Markup Language
: You can now pass Speech Synthesis Markup Language (SSML) to the HTTP GET and POST versions of the /v1/synthesize method.