Setup with Apple store

June 21st, 2013 No comments

Two things. First I’m playing with the mobile WordPress application. It would be great to be able to write posts offline. I’ve got flights that need to be filled and the laptop only lasts so long. So this is my first offline post.

Onto my little hang up, I wanted to register for an organization developer account. I immediately ran into a stumbling block: a DUNS number is needed. I’ve got the IRS number but guess that isn’t good enough. It’s not that I mind proving I’m legit, just wish there weren’t so many hoops.

The real frustrating part was I went to the D&B site to sign up and they wouldn’t take my info. I went back to the Apple site and submitted it there. At least I got a confirmation back from D&B that the got the info and are reviewing it. Progress at least.

Hopefully my next post is more upbeat and interesting….

[Update] This morning I got a call from D&B. Very friendly and professional. Quick verification of my information. All in all a much better experience then I was expecting. Should get the number in a day or so…

[Update 2] got a call this morning from Apple. Everything is approved. Other than taking more time than I think it should have, it’s done. Just in time to play over the holiday week.

 
Categories: mobile

Going Mobile

June 16th, 2013 No comments

The mobile revolution has been huge. I’ve been concentrating on my career for the last couple of years and got away from the day-to-day playing around with technology. I’m now getting back to it (even in a limited manner). I want to create a mobile app to see what’s out there. I’ve played a bit with the different native platforms (iOS, Andriod) and ended up finding m-gwt. Yeah…I am able to re-use my java/gwt skills and create a mobile app.

I have started to create a pretty simple little app and am putting the final touches on skinning it. I’m working to get it uploaded so I can see it on a real device. More to come on what I find out.

Chris….
on LinkedIn

 
Categories: Gwt, mobile

Recurring Paypal Wilderness Jaunt

August 12th, 2010 No comments

Everytime I sit down to implement more of the paypal interface, I feel like I am heading into the wilderness with a rough outline of the territory. The latest venture was to add the ability for our ecommerce solution to process recurring payments via paypal. We allow this for credit cards already; but paypal is a different beast.

This time I sat down and after reading the documents quickly to get my bearings, I did the design and then started coding. What I left out this time was the exact protocol pieces. This time I was going to learn the protocol via experimentation.

I was not disappointed. While the paypal docs get their own protocol about 90% of the way there, they left off critical things and it will not work until you get it 100% right – nothing new there. The first is, what should the date format be. They say the date should be sent; but do not specify the format. Fortunately a quick google found several examples. For future reference the first billing date format is: yyyy-MM-ddT00:00:00Z (I just hard coded the time to midnight).

Second, the documentation is confused about what is required and what is not. For example, the docs say the address fields are required. However, I did not put them in for my first experiment and everything worked out just fine. I’m guessing the address fields are only needed if you put in an address.

Third the docs are just wrong! The response field with the status of the recurring profile is called STATUS in the docs. Hey paypal, it’s PROFILESTATUS. Easy enough to figure out, but come-on.

Now that I can create a basic recurring profile in paypal, I’m off to create a LOT of test cases. I’m particularly concerned about what happens when using direct payment (i.e., credit card gateway mode) and recurring payments. There is some vague language about this being different, so I need to find out what they mean. For starters, all paypal tx pass back a token id. However, the docs say not to use that with the use case. Instead, we need to pass all credit card info back to paypal. Geez, what a pain. Paypal already has the information linked to that token id, it would be simpler and more secure to just use it as the reference – just like we do for the non-credit card recurring payments. Guess I’ll have to create a 2nd similar code path to account for this….

Overall, I’m pleased with what I see as far as functionality provided by paypal. I just wish thier documentation was correct and clear on the specifics.

 
Categories: Java, paypal

Paypal Does it again

July 6th, 2010 1 comment

We’ve had they paypal direct pay API implemented for some time. We just ran our automated tests and they ALL failed. Turns out paypal changed their sandbox environment (again). If you use this api you need to make sure to always pass the cvv2 code; otherwise the payment request will fail.

It’s not a big deal that they want to always require the cvv2 code. The big deal is they just did it without letting anyone now, or make it easy to find out what a valid cvv2 code is that can be used. Turns out it is “000″. I only found that because there is a post on the site from one of the pp developers.

https://www.x.com/message/177346#177346

Sigh, I really don’t like commenting on other people’s apps (everyone has problems); but paypal is so difficult to work with I sometimes need to just vent….

 
Categories: paypal

It’s tough to overload our GWT RPC

June 26th, 2010 7 comments

Actually, it wasn’t too bad once I worked through how I wanted to load test a GWT app. We have lots of tests for the GUI portion which obviously also test the RPC/server side; but we wanted to really stress test a few RPC paths.

Fortunately, we are not the first. We needed a mechanism to simulate RPC calls and with a little digging (actually, it was pretty hidden in a mess of less than helpful posts), we found a rough and ready class that we used – easier to borrow something than to build from scratch. Here is the project page:

http://code.google.com/p/gwt-syncproxy/

Once we adapted the code to our specific case and removed the app engine stuff, we were good to go with a quick framework that lets us write RPC test cases that look like:

RPCService service = 
       (RPCService ) SyncProxy.newProxyInstance(RPCService.class, 
                                                "http://mydomain/my-web-app/",
                                                "path");
String result = service.executeRemoteMethod(param1, param2);

We use the SyncProxy to instantiate the RPC service, than call a method on the service interface and wait for the result. That’s my definition of easy to use. The great thing is the test code is synchronized so we don’t have to worry about ansyc calls in the test code and can evaluate the result for correctness immediately.

Next up is to use Apache JMeter to simulate load. This again is relatively easy. By implementing the JavaSamplerClient of JMeter, we can add our test case as a java class that gets executed. There is sample code available – take a look at SleepTest included in the source download.

We did have to modify the source code to add the ability to include the CookieManager in the JavaSamplerClient. This required a bit more digging around and modifying of JMeter but is doable in an hour or so and changes 3-4 JMeter files in the java protocol package. If you want to do this, look at the HTTP protocol package. We did this because our code retrieves cookies via a standard HTTP call first and then calls our java test case which needs to access the cookies. Other than that, we used the stock framework and can easily load test our app.

In fact, with these two pieces (SyncProxy and JavaSamplerClient) we quickly write test cases for the critical parts of our app that we want to load test. That’s my task for next week – yeah!

The great part is after a day of testing different components, our performance and scalability is even greater than what we thought it was (ok we did make one minor change to remove some contention) and we have lots of room for growth with our current architecture.

The only part I couldn’t figure out was how to get JMeter to add our jar files to it’s internal classpath. We tried using the search_paths and user.classpath parameters, but nothing we did seemed to allow JMeter to pickup our jars from a different location. It’s just an annoyance to have to build the components and then move the jars to the ext directory of JMeter. Would be nice if we could get the search_paths parameter working. Oh well, maybe another day.

All in all, it took about a day to become familiar with these tools and write our test cases to cover our most frequently used code paths.

 
Categories: Gwt, Java