I have been using Affinidi's APIs (https://affinidi.com/api) for credential management and right now they provide few set of VC types. I want to create my own VC type and use that in my project. How can I create a new VC type such that the creation and verification works as it is.
Affinidi currently uses the open-source #affinidi/vc-data repository to manage VC schemas. Feel free to contribute your new VC schema to this repository and we will help you get it merged. You can find detailed information regarding how to create your VC schema here.
Before creating a PR, you may also want to check recent VC schema PRs to the project to not miss anything. Here is a PR for VCGrantWinnerV1 type, which includes all necessary changes(definitions, exporting, version bump, unit tests).
P.S. We are working on "Affinidi Schema Manager", a new product that will let you create and publish schemas without any coding. So stay tuned for that.
Related
We have a self-hosted GitLab FOSS instance. This version does not include any epics/stories and there is build-in way to create hierarchy between issues.
We are migrating a project from JIRA. The team that worked on this project where using epics/stories and sub-tasks. Are there any strategies to handle epics/stories in GitLab FOSS. I mean I know we would have to use labels and/or milestores, but has anyone ran into this situation.
Also, I know GitLab Ultimate has epics, but it is too expensive.
Epic in GitLab are indeed part of the "Portfolio Management" feature (issue 3254) of the GitLab Ultimate edition.
The only free alternative would be to have "sub-issues", which are being discussed in issue 4588, and illustrate how you would need to use labels.
For instance:
All sub-issues must use the same prefix for their title, preferably a meaningful shortened version of the main issue's title if it's too long.
This is a visual helper to quickly identify sub-issues and their main issue.
Each sub-issue must have proper labels:
the ~sub-issue label
the same type label as the main issue
the same release scoping label as the main issue
the same priority label and severity label as the main issue
the relevant specialization label to that particular sub-issue
This is still being implemented, with topics like "Provide first class support for Issue Task Lists and Tasks" (issue 2036).
Update March 2022 for GitLab 14.9 (Ultimate edition only)
Link an epic to another epic
GitLab now supports linking epics using “related”, “blocking,” or “blocked” relationships.
This feature enables teams to better track and manage epic dependencies across GitLab groups.
Effective dependency management is a key component of reducing variability and increasing predictability in value delivery.
I wanted to check out the inner workings of the Spectator View feature, but I got stuck.
Checking out the Repo, Unity complains about missing the HololensForCV.dll. I didn't get very far.
I found the Microsoft HoloLensForCV repository, but could not compile it. I'm not even sure, if it did, that it will spit out the desired dll.
How do I get the branch to work?
Update:
We have migrated to a new repository with samples and better documentation, please take a look here: https://github.com/microsoft/MixedReality-SpectatorView.
==================================================
Could you please try checking out this branch:
https://github.com/microsoft/MixedRealityToolkit-Unity/tree/prerelease/2019.build.spectatorView
We have documentation for SpectatorView specifically here:
https://github.com/microsoft/MixedRealityToolkit-Unity/blob/prerelease/2019.build.spectatorView/Assets/MixedRealityToolkit.Extensions/SpectatorView/SpectatorView.md
Please give it a try, and let me know if that helped.
The feature/spectatorView branch in the Microsoft MixedRealityToolkit-Unity repo no longer has any scripts with dependencies on the dlls built out of HoloLensForCV. It may be worth checking your commit log to see if it matches with the current commit history for the feature/spectatorView.
FWIW, the main feature/spectatorView branch is undergoing a lot of refactoring/breaking changes. We forked the prerelease/2019.build.spectatorView branch so that folks could start looking at ASA localization for spectator view without having to be broken by rapid development underway in the feature branch. This prerelease only supports ASA localization for an android and HoloLens (1 or 2) device. ArUco marker and QR code based localization is in progress but not yet supported.
We are building a custom Visual Studio build task to implement compliance validation of the builds defined by our developper teams.
The objective is to mark builds using "unauthorized" tasks, or failing to use mandatory tasks in a way that will be possible for a BuildCompleted servicehook to act upon later on.
We are creating a JSON structure describing the different business rules we want to enforce, and we have a service hook catching end-of-build events to create a tracability file that will mark the build artifacts as "deployable" or not.
I can see from the MS references that a Issue collection is returned with the GetBuildDetails responss that seems to list exactly the kind of information we'd like to pass along.
Anyone found a way to populate that property?
Thanks!
The solution is add additional information to the build result by using Logging Commands (e.g. ##vso[task.logissue]error/warning message)
We are authoring Azure Resource Manager templates. We are using the following deployment template schema, because it is the one that we saw in an example.
http://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#
It is from early 2014. Where can we find a list of more recent schema versions?
We have looked at the list of resource Manager providers, regions, API versions and schemas. It references a schema for each provider not for the entire template.
When we do find a list of more recent schema, how do we evaluate which deployment template schema to use? Is more recent better?
Here is our current hack:
Go to https://github.com/Azure/azure-resource-manager-schemas
Press t to enter the [GitHub File Finder][3].
Type DeploymentTemplate.
Voila. We have a list of deployment template schema, which displays two API versions.
More recent is better. But in general you should be able to stick with the top level schema of:
http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#
That will pull in the proper version of all the child schemas. We update the child schemas so all your existing templates don't have to be updated. Multiple API versions are supported in the child schemas to support "backward compat".
If you do peruse GH, look at the readme.md (that tells you what to test and therefore what's in use) and the file you want to watch is:
https://github.com/Azure/azure-resource-manager-schemas/blob/master/schemas/2015-01-01/deploymentTemplate.json
As that's the top level schema file.
Still no official list in 2020, until we found one, here's the current root schemas for quick reference
Resource group:
https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#
https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#
https://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#
Subscription:
https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#
Management Group:
https://schema.management.azure.com/schemas/2019-08-01/managementGroupDeploymentTemplate.json#
Tenant:
https://schema.management.azure.com/schemas/2019-08-01/tenantDeploymentTemplate.json#
This will definitely be outdated in the future, this is sourced from here so be sure to check too if you want the latest. Feel free to update the list in the future.
I was searching for same answer, found this question.
Sorry for all those who answered before, i wasn't satisfied with the proposed solutions.
So i found another way, maybe this is suitable :)
At this page https://learn.microsoft.com/en-us/azure/templates/
you'll find on the left side a list of all types of resources that can be defined in an ARM template.
For each resource (e.g. CosmosDB) you'll find a link with All resources (e.g. https://learn.microsoft.com/en-us/azure/templates/microsoft.documentdb/allversions for CosmosDB) which lists all versions for that resource.
Hope it helps!
p.s.: also there's the link of Latest (e.g. for CosmosDB https://learn.microsoft.com/en-us/azure/templates/microsoft.documentdb/databaseaccounts) which gives the latest format of that resource ;)
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.