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.
Related
I've looked at so many articles in the past year without finding an answer, I'm starting to go crazy...
I do a lot of application support and use the Event Viewer on a regular basis. On any machine but mine, when I look at an event with Event ID 0, the "data" part of that entry is shown in the General tab of the viewer. This is the default behavior that I like. On my laptop, however, for about a year now, Event ID 0 shows as "The operation completed successfully." I no longer see the "data" part of the event in the General section of the window.
Example of the annoying message
The only thing I can think of, is that I added a custom description (or definition) for Event ID 0. But frankly, I don't know how I did it, if that is the case. I want to go back to seeing the "data" in there, rather than this useless message.
Does anyone know how to fix this?
While not a "fix" to the problem, I have what may be a workaround for you.
First, I can confirm that I have experienced it also--and it's been on MORE than one computer. But it has been limited to only some apps ("sources", in event viewer parlance). So I am assuming it's THEIR doing rather than ours. Your situation may be different.
But second, and until you may find a better solution, I will note also that there may well BE a useful message for you to see. If you click on the Details tab above that message, the "friendly view" of the details will readily show what the "real" message is that underlies that log entry.
See this screenshot showing a Postgres startup message that was hidden under such an "operation completed successfully" log entry.
I have seen it and other apps/sources work this way for such startup status messages, failures, errors, and more.
Like you, I lament that we should have to know to do that. It feels to me like the folks creating the code that create the event log entry are making some choice that leads to this behavior. At least now I know that I can SEE the info they are trying to share, albeit via what seems a poor choice.
I need a sample file for the latest Scenarios of AATS Testing. We generated the code for this and want to check the against to accepted one.
"Latest scenario" is always changing. More importantly, why don't you just submit your XML and see what response you get from the IRS? If they accept it, there's no need to do anything else. If they reject it, they will indicate where it failed. Either way, there's no need to see anybody else's XML.
You can find the current scenarios and answer keys for the scenarios for AATS testing at the following link:
https://www.irs.gov/for-tax-pros/software-developers/information-returns/affordable-care-act-assurance-testing-system-information
Edit:
Be sure to review the "AATS Scenario Known Issues and Solutions" link. As of this post, that document was last updated on 4/26/2016 and mentions some issues that have been reported and solutions for them.
Xpage (listPostits.xsp) has a "View" container control, where one of the column is set "show values in this column as links".
Now, here comes "Strange behaviour".
When i work with this application on my own (developer) PC (Win XP, Chrome or IE), the Domino generate the link, which can't be really processed:
/servername/db/postit/postit.nsf/listPostits.xsp/onePostit.xsp?documentId=many_numbers&action=editDocument
Namely, the Bold-marked portion shouldn't be there ! This portion is the name of the XPage, where the View control is in.
When i work with the application from other PC (Mac, Firefox) then i get the correct link (the same as above but without the XPage name inbetween):
/servername/db/postit/postit.nsf/onePostit.xsp?documentId=many_numbers&action=editDocument
update: let us leave for the moment the differencies in generated links between two machines. The first question is - why the extra portion is inserted into automatically generated link?
After playing around i think i might have found the reason for this strange behaviour. Namely, the "Substitution" Rules on the server side. One of them is to substitute "*/postit/all" with "/db/postit/postit.nsf/listPostits.xsp"
If i switch it off, then the Links are generated properly. Still, it's pretty strange to me that these settings influence the way Domino generates the links. I thought it works on the fly with them and those settings have nothing to do with the way how Links are generated inside the application.
So, the help now is needed regarding Web Site Rule Topic, but for that, i guess, i have to create another topic. But in case somebody has some good Info on this, please share it with me. I'm a bit confused at the moment :)
Final Update: Spent some more hours of testing and the results confirmed the initial idea.
If i open the page with the standart URL, i.e.
http://servername/db/postit/postit.nsf/listPostits.xsp then everything is fine, links are generated properly. When i however open the same page with short URL http://servername/postit/all , then server adds the substitute URL (db/postit/postit.nsf/listPostits.xsp) to every single link he generates automatically to be used as the link to open/edit the underlying document.
Is it bug or feature ? Don't know.
As a workaround (because i want to keep simple URL's for the application) i have to manually generate links.
I was in http://finance.yahoo.com/ and checked the europe tab ( markets are open here atm) you ll see trades updating live, I went to firebug to the Net tab and there was no updates... so I wonder how are they doing that?
I can see there is a streamerapi.finance.yahoo.com that actually makes fiddler throw an error.
Anyone knows anything else about this live update?
Really interested in this, would really like to know if they are constantly polling , the updates seem to happen at irregular intervals
found some info here
Please note my interest is on the seeminly push aspect of it ( ie view is updated when there is new information)
Cheers
It is called Comet.
http://en.wikipedia.org/wiki/Comet_(programming)
It is a comet system using a hidden iframe technique. A step by step description of what is going on with streamerapi as well as a simple debug HTA to consume the feed is available on my site: AJAX Push – Comet.
An obscure puzzle, but it's driving me absolutely nuts:
I'm creating a custom Information Management Policy in MOSS. I've implemented IPolicyFeature, and my policy feature happily registers itself by configuring a new SPItemEventReceiver. All new items in my library fire the events as they should, and it all works fine.
IPolicyFeature also has a method ProcessListItem, which is supposed to retroactively apply the policy to items that were already in the library (at least, it's supposed to do that for as long as it keeps returning true). Except it doesn't. It only applies the policy to the first item in the library, and I have absolutely no idea why.
It doesn't seem to be throwing an exception, and it really does return true from processing that first item, and I can't think what else to look at. Anyone?
Edit: Cory's answer, below, set me on the right track. Something else was indeed failing -- I didn't find out what, since my windbg-fu isn't what it should be, but I suspect it was something like "modifying a collection while it's being iterated over". My code was modifying the SPListItem that's passed into ProcessListItem, and then calling SystemUpdate on it; as soon as I changed the code so that it created its own variable (pointing at the exact same SPListItem) and used that, the problem went away...
There's only a couple of things I can think of to try. First, are you developing on the box where you might be able to use Visual Studio to debug? So just stepping through it.
Assuming that's not the case - what I'd do is fire up WinDBG and attach it to the process just before I registered the policy. Turn on first chance exceptions so that it breaks whenever they occur. you can do that by issuing the command "sxe clr" once it is broken in. Here's a little more info about WinDBG:
http://blogs.msdn.com/tess/archive/2008/06/05/setting-net-breakpoints-in-windbg-for-applications-that-crash-on-startup.aspx
What I'd do is then watch for First Chance exceptions to be thrown, and do a !PrintException to see what is going on. My guess is that there is an exception being thrown somewhere that is causing the app to stop processing the other items.
What does the logic look like for your ProcessListItem? Have you tried just doing a return true to make sure it works?
Some nice ideas there, thanks. The Visual Studio debugger wasn't showing an exception (and I've wrapped everything in try/catch blocks just in case), but I hadn't thought of trying Windbg...