Does History.back() work in a GWTTestCase? - gwt

Does History.back() work in a GWTTestCase?
I have tried verifying the current token immediately after History.back() call and also after a delay using a Timer but it doesn't seem to change. The onValueChange() method doesn't seem to be called either.
I did a Google search for the issue and found a few posts that suggest others have experienced a similar problem but some are dated 2010. I did find one post where Thomas Broyer responded to one person that he observed the same but I am unable to find that post again.
Has anyone had success in testing code involving History.back() from GWTTestCase? If so, I am most likely doing something wrong. If it is a known issue or intended behavior I would appreciate knowing that so that I don't spend any more time on this.

Judging by GWT's own tests, it should work, but maybe has quirks.

Related

Exposing tags to Google Scholar

I want Google Scholar to detect and consider academic papers on my website. I implemented tags as required in [http://scholar.google.com/intl/en/scholar/inclusion.html], time passed (more than 3 months), and they still ignoring my metadata. I checked over and over, and nothing happens... any ideas on how to check this in a realistic way?
Google says some of they refresh takes more than a year.... it is dumb to wait a year to notice there was a bug... and then again wait for another year...
I have similar problems with Google Scholar. Unfortunately, there isn't much you can do. GS support isn't helpful at all, and indexing can take that much time. Sorry.

Widget API accepts clean friendly URLs

In the past the widget HTML5 player API was not accepting sound clean friendly URLs,
only with a track ID.
But now when I try it, it seems that it does works fine, but I don't see it mentioned anywhere in the official blog or something.
So my question is: is it safe to use it please?
Using:
http://w.soundcloud.com/player/?url=http://soundcloud.com/user-name/track-name
Instead of:
http://w.soundcloud.com/player/?url=http://api.soundcloud.com/tracks/13692671
And also if you got any status of fixing the serious bug where the events are not firing, I will love to know please.
The events should be all firing properly now.
Yes, you can use friendly URLs, however, as we have to resolve them on our side, initial load of the widget will be a tad slower. So for the faster loading it is still recommended to use API URLs.

Parsing Google's search results

I'm "working" on a data mining project and I've chosen to parse Google search results. Now before I actually start, I want to consult you - experienced folks.
I did a bit of research on how Google delivers results and I analyzed structure of a result page. That's all alright, I've already figured out regexes and data structures I'll use.
In between I encountered their CAPTCHA because I was searching too fast; oh, the irony. I've also discovered that they limit results to 1000 actually. Now, is there any way I could avoid those peripeties, perhaps slowing the rate of url fetching to solve the first one or reporting when encountering CAPTCHA so that it waits for my input; that might do it, but what about the other one ? Does Google provide some kind of an API that I can use for a workaround? I couldn't find one on their code.* page.
There is a Custom Search API.
It returns results in json or XML, so you won't even need to use regexes. However, you do need to pay for more than 100 searches a day.
What exactly are you trying to do? Maybe there is a better way to accomplish it.
Always look on CPAN first!
https://metacpan.org/pod/REST::Google
If someone hasn't already solved your problem, chances are it's a weird one :-)

Has anyone tried the trac to fogbugz conversion/import tool?

http://our.fogbugz.com/default.asp?W977
I suspect it will be a simple task, but just thought I would ask before I tried it.
If you have used it, how did it go? Any caveats or things to help? Can the changes be undone automatically?
Anything you would have done differently or configured in trac beforehand to make it go easier?
By the way:
I am pleased with my initial trial of fogbugz, Nothing wrong with trac, but I really wanted an autoresponder and a way for emails to support#mycompany.com to create a new ticket and reply. It is just so professional.
Curious about the project estimation, but that was not a factor. I am looking forward to trying that.
I tried it and it choked on our Wiki pages. I wasn't particuarly excited about the way the import tool mapped the Trac fields to the FogBugz fields.
Another issue is that you can't really delete issues once they're in FogBugz, so after the first failed import I just closed my Student & Startup account and opened a new one.
I ended up transferring our ~100 bugs manually because I decided too many of them were stale and it was worth the time it took to personally look at each one and rethink the priority. If you have more bugs or aren't at a point in your project where stepping back and looking at the whole To-Do list in that way would make sense, that might not be an option.
All that said: I'm loving FogBugz. The fact that our users and testers are getting confirmation emails with links to their tickets is forcing us devs to be more responsive to incoming requests, and the email tools make it easy to have a conversation about each issue. In my case, the import pain was worth it.

Has anyone found payment processor documentation very poor

Does anyone else find that the documentation of a lot of payment processors have poor or incomplete documentation as to how to use their API? Or it's just plain confusing?
Recently I have setup both PayPal and Beanstream and found that both are either confusing or don't include full documentation.
For example, in the BeanStream documentation, they say they will return a "message_id", which is great, but no where do they tell you what the different id's mean. It also comes with some text, so you can start creating a list, but there is no way to check to ensure you get either a valid one or the one that means it was successful.
Has anyone had this experience?
Edit: I will agree that when you email them they are helpful, but unfortunately most of them are only open normal business hours for general tech support (other than emergency) which isn't always useful as that isn't when it seems like I do my integration.
well, this isn't really specific to payment processor documentation, in that, all things being equal, well documented APIs will help encourage development. for what it's worth, i've worked with paypal, authorize.net, ups, and usps APIs, and didn't find them overtly confusing (not implying that they were a particular joy to get through).
that being said, i wish more documentation was like PHP's. despite it being such a scattered language, the documentation is really quite good.
Having worked with a lot of APIs, not only for payment processors but for lots of other ecommerce related web services, I have to say to that while the docs can be less than stellar, they usually aren't that bad, and if you send them an email or give them a call, they will usually be pretty helpful.
I have found the documentation and code examples from Authorize.net and Nova's ViaKlix very helpful. I stay away from PayPal.
This may not be much help to you, but as you get more an more experienced w/in particular domain the interfaces get easier. By weird twist of world, I've coded a whole bunch of credit card interfaces, and once you kind of get the lingo they all work the same.
The only other suggestion I would offer is to avail yourself of support resources in addition too the documentation provided. We recently worked with a relatively well known payment gateway, and while their documentation completely sucked (by their own admission as well), the support staff was incredibly knowledgable and more than willing to help out/explain.
I've used Realex and PayPal. Realex documentation is fine. Clear and straightforward. PayPal's is absolutely eye-bleedingly horrible. And I'm the kind of weirdo who enjoys reading documentation so much I've been known to read it for fun (I've read through the entire OpenID specificiation, even though I have no immediate plans to use it).
I've only worked with PayPal, but the simple version (where you just set up an HTML form on your web page and submit it with the PayPal button) is super-easy to work with. And if you're looking for near real-time payment feedback, I always found it easier to just write a program to check my PayPal email account periodically, and parse payment details from the body of the email itself.
I've had to use Authorize.net for several sites and the supplied documentation is 'just ok' assuming you are working in the somewhat limited technology sets that they supply sample code for. It was a breeze to get it up and running with PHP but considerably lacking when trying to pull off the same thing in ColdFusion.
Several other sites done via PayPal which IMO was a much better experience.
PayPal is a nightmare when it comes to setting up and testing the test account (Sandbox).
Re: Beanstream you have to login then you'll see the documentation link on the left hand side.
The design is so '90s and they recommend using IE.
Re: Paypal I adapted this code from http://www.php-suit.com/paypal for my Zend Framework project.
Note: you've got to have ssl:// socket transport wrapper registered otherwise (visible in phpinfo()) you'll have to tweak the code to use curl.
Here is how to get the code using SVN
svn checkout http://paypalphp.googlecode.com/svn/trunk/ paypalphp-read-only