How to make the latest SpectatorView work with MRTK RC2? - mrtk

It is clear that there has been a lot of updates on the subject, however not much documentation is (yet) available, as far as I'm aware of. I downloaded the most recent commit from the feature/spectatorview branch of MixedrealityToolkit-Unity, and copied the MixedRealityToolkit.Extensions into my MRTK folder.
Now some of the noticable changes has to do with the PlatformSwitcher-holding prefab "SpectatorView - HoloLens". The script is marked as "SpectatorViewOld" and it could be interpreted as this is a deprecated prefab. There's also SpectatorView.ASA.HoloLens/Android, however these prefabs are seemingly having missing scripts, which prevents them from being usable in a project.
My question is, if there's an up-to-date guide on how to implement the SpectatorView, and if so, where can I find this/How do I go about it? Should I stick with an earlier commit?

Update:
We have migrated to a new repository with samples and better documentation, please take a look here: https://github.com/microsoft/MixedReality-SpectatorView.
==================================================
Yes, we currently have a stable branch that matches what we showcased at //BUILD:
https://github.com/microsoft/MixedRealityToolkit-Unity/tree/prerelease/2019.build.spectatorView
And, documentation for it here:
https://github.com/microsoft/MixedRealityToolkit-Unity/blob/prerelease/2019.build.spectatorView/Assets/MixedRealityToolkit.Extensions/SpectatorView/SpectatorView.md
Please give that a try.
We are still in active development as we push towards a V1, and soon will be cleaning up all the deprecated files and polishing of our documentation.

Related

npm: Tool to check flag packages that are not properly maintained / check against criteria

I am looking for some tool or npm package that we can use to verify our used npm packages against certain critiera, e.g. that is was updated in the last 6 months or whether it has a certain license (e.g. MIT).
Especially the check regarding the last update date seems to be not that popular as I couldnt find anything regarding that.
In the best case, something that we can integrate with GitHub Actions so that we can automate that check.
Thanks a lot!
Greetings,
Philip
I already looked for tools / ways how we can get that data, e.g. npm show or https://packagequality.com/. However, all of them would require us to do some scripting ourselves, which I am trying to avoid.
I didnt find any tool that could be used for that, but I found a way how I can fetch the relevant data from the NPM Registry.
Requesting the following endpoint (e.g. for axios): https://registry.npmjs.org/axios/
This will return a key called time that contains the release dates of all the releases. You can then just select the latest version of it and get its date.
Consider run dependencies checker tool that npm built-in
https://www.npmjs.com/package/depcheck
It might not satisfy your needs in certain areas

Recommended way to find out what Liferay module provides a class

In my Liferay module, I want to use Liferay's SomeConvenientClass.
What is the recommended way to find out what module provides that class?
So that I can quickly add it to my build.gradle.
Ideally it should either:
return the module's group/name/version,
or say with certitude that this class does not exist in Liferay or is not exported.
Until now I go by trial-and-error and copy/paste from build.gradle files found in the wild, but I am looking for a more reliable method.
I have Liferay installed, and the source code of the exact same Liferay version, if that helps.
I tried mvnrepository but it does not seem to return anything, example: https://mvnrepository.com/search?q=AuditMessageProcessor
Have you tried http://search.maven.org/#advancedsearch ?
For example:
http://search.maven.org/#search|ga|1|c:"AuditMessageProcessor"
This is more an option than a real thing, but this is how I normally do:
be familiar with package naming conventions used by liferay and
inside apps: api, service, web...
be familiar with the bundle structure used by liferay, as their
use of resource folders, which are not so obvious sometimes...
With that in mind, normally on github is enough to navigate: portal->(kernel/impl/services/apps)->app service/api/web...
But this is a natural process that comes when you spend your day inside the code.
Normally, online jar locators help, but quite often I just rely on my IDE.
On my IDE I have all set-up with Spring dependency management, after I extracted the dependencies using Gogo shell with a running bundle. With Gogo you will not find classes, but modules and packs will be listed. (Gogo is probably what you are looking for btw, as it is able to list with version numbers)
Bottom line, if you need a list as a picture of a running environment, use Gogo.
With regards to the master code, just do not trust it! When it comes to modularity and bundles versioning Liferay is pretty messy (read The dependency management problem here: https://www.e-systems.tech/blog/-/blogs/liferay-digital-experience-platform-review-7-0-ga4).
For your step 7, you will need to chose an api version and code against it. The apis are more stable. You can impose a limit for compatibility on you bnd file, which will cause the system to issue warnings. On your environment, you can catch api changes earlier, let's say, you can ask gradle to use a module with an version number but any patch (using the "+" sing), when you build with a fresh cache or if you change gradle resolution strategy to download you dependencies more frequently, if the build breaks, well, you will see it.
Helpful start point: https://dev.liferay.com/pt/develop/reference/-/knowledge_base/7-0/using-the-felix-gogo-shell
This is how I do, it is slow and manual, so don't hesitate to suggest other methods.
Download Liferay's source code if you don't have it already.
Run find . -name SomeConvenientClass.java. If nothing is found, you can be sure the class is not part of Liferay.
In the path to the class, find the src folder level, and go just under that, so for instance if it is modules/apps/collaboration/document-library/document-library-web/src/main/java/com/liferay/document/library/web/portlet/action/DLViewMVCRenderCommand.java then go to modules/apps/collaboration/document-library/document-library-web/.
Hopefully there is a bnd.bnd file there, open it.
If the package of the class is not in the Export-Package section, then either give up (duplicate Liferay's code into your module), or use some dark tricks. If you believe the class should be exported, you can explain your case at https://issues.liferay.com/browse/LPS-70480 for future generations to enjoy.
Module name is the value of Bundle-SymbolicName.
Version is the value of Bundle-Version.
Group is probably com.liferay, although sometimes it is com.liferay.portal, not sure how to tell.
Build. Sometimes it fails because Maven repositories are missing a version, for instance com.liferay.document.library.web 1.0.11 is not available despite being used by DXP fix pack 30. Not sure what to do in such cases except choosing a "similar" version and hoping for the best.

How can I prevent Glimpse 1.8.2 from posting to api.mixpanel.com?

At certain times in its operation, Glimpse 1.8.2 POSTs to api.mixpanel.com.
What is it sending?
How can I stop this from happening?
How can I opt out?
From "avanderhoorn" at https://groups.google.com/forum/#!searchin/getglimpse-dev/mixpanel/getglimpse-dev/7WgpX_Menz4/tnqJBwt20ZgJ:
I'm sorry this caught you off guard, that is not our intension.
This is to be expected and went out with the last release - http://blog.getglimpse.com/2014/02/04/glimpse-1-8-2-released/ (see Glimpse Insights support). Its a part of an effort to try and make better decisions for choices we make -http://blog.getglimpse.com/2014/01/22/getting-greater-insights-into-glimpse/.
It is a part of core but when switched off, its a complete removal (from the blog post):
If you do opt-out, there will be no traces of Insights in your code base. Insights was designed not simply to be a switch on or off, but to be a complete removal. Meaning no traces of the Insights code will remain if you choose to opt out.
The information being gathered can be viewed if you have a look at local storage. If you want a better view than that, you can get the client repo - https://github.com/glimpse/glimpse.client/ - and running the test client - https://github.com/Glimpse/Glimpse.Client/blob/master/test/Client.html. Once you have that open you will see a tab called "Insights" on the right which shows the data as its being collected. Also, if you want to see the source code involved, its isolated to this one file - here is the specific code that captures the events https://github.com/Glimpse/Glimpse.Client/blob/master/source/glimpse.insight.js#L345-L520.
You are right about the fact that it should be on the site. We have a new site coming out soon and its noted there. Its an oversight and the fact that we have been focusing on the new stuff. In response to an earlier question - https://twitter.com/greensky/status/431491507590160384 - we have also updated the Glimpse.axd to have the code required to opt-out. This will go out with the next release.
As an action item on this, I'll update the config help page of the current website to make sure the same information thats in the post will be noted there. Also I would like your feedback if there is anything else you think we can do to help. For the sake of completeness, the following is the opt-out code which goes in your web.config:
<glimpse>
<clientScripts>
<ignoredTypes>
<add type="Glimpse.Core.ClientScript.Insight, Glimpse.Core"/>
</ignoredTypes>
</clientScripts>
</glimpse>
Lastly, as we get time, we will be making the data collected publicly available. If this is something you are interested in helping out with, we could sure use the help. We believe that information like this will not only help us make better decisions, but help the community inform us what they want beyond what we here from the occasional person on twitter or at conferences.
Let us know what you think.

JIRA plugin to view previous issue status

I am looking for a JIRA plugin that will show the status of issues at a previous date I give it. So if I tell it Monday of last week, I would like all of the issues that existed at that time with their status at that time. I was wondering if such a plugin existed or if there is another way to go about this. Thanks for reading and for any help you provide.
*Note, I made a excel macro to basically do this but it includes a gigantic mysql query that I would not like not to use if such a plugin already exists.
I don't think that such a plugin exists at all because this would involve issue statistics to show how the issue changed over time.
You can post an feature request with the Atlassian JIRA team to see if this is possible or not. They could also include this feature in a future release or a proprietary plugin if they see that there is enough interest.
http://www.atlassian.com/resources/support

RollingFileAppender: preserve the file extension without log4net patch

M question is related to this one as I have the same problem. How can I make the RollingFileAppender of log4net preserve the file extension without having to actually "patch" (i.e. create an interim build of the current trunk) log4net? How could I achieve the same thing by overriding the RollingFileAppender or creating any other extension with the least effort?
As mentioned in my comment, you're not required to "patch" or change anything in log4net. You cannot use the 1.2.10 release, though. It is a rather old build, but the PreserveLogFileNameExtension is in the current source. You only have to bring down the source and compile the dll yourself and you're good to go.
Update: I see your concern. IMO, the only way is to make a build and test it. To further your confidence you could review the current list of resolved (and unresolved) issues for 1.2.11. I would think that seeing they are not doing a major revision, changes are mainly bug fixes and additional features.

Resources