Been battling some Twitter code I wrote a few months ago that first posts a status update to a Twitter account using /statuses/update.json, then allows a user to retweet using /statuses/retweet/[tweetMessageId].json to another Twitter account.
When I tried the routine this morning it steadfastly refused to send the re-tweet. The Twitter api just returned 'Not Found'.
I tore all the routines apart, added debugs everywhere, without success. Then, staring at the returned JSON values, with the database open on another screen, I finally twigged.
When I post the Tweet I'm grabbing the message ID number and saving that to the database. Then, when I want to retweet, I use that message id in the retweet end point.
A couple of months ago the message Ids were 11 digits long, now they are 16 digits. I'd been grabbing the 'id' value coming back from Twitter, but a number that long was getting truncated by my JSON parse routine (I'm using the very handy JSON2 library). I checked the JSON values and Twitter very kindly also sends back 'id_str', which is the message id as a string. For example the JSON contained:
Indeed, now I look more closely, I can see that they also send back the ID of the Twitter account using the same, for example:
I guess the explosion in the message Id in the past few months just continues to underscore the remarkable growth in Twitter's scale, presuming the message ID values have simply been incrementing sequentially over that time and haven't been jumped ahead manually for some reason.
Had cause today to want to retrieve and archive voicemails and text messages from my iPhone4 to my Mac. Hunted around a little bit – for example found advice that the only way to transfer a voicemail to my Mac was to plug in an audio cable from the iPhone's headphone jack to the Mac and essentially 're-record' the audio of the message.
That didn't sound too much like fun, then came across Decipher Media and their iPhone Tools. Isn't it nice when someone offers software that does exactly what you want, in a simple, understandable fashion, at a price that doesn't affect whether you eat for the remainder of the week.
They have two products, one called DecipherTextMessage, and another called DecipherVoiceMail. Bundle was $7.99.
You install the software to your Mac. You backup your iPhone (via iTunes). You run the programs and they retrieve your text messages and voicemails from the backup files on your Mac – note, NOT from your iPhone.
Interestingly not only did they find messages from my iPhone4 (which I've only had for a few weeks), but also my previous iPhone – whose backup is clearly still hiding away on my Mac.
For example, despite the fact I have long ago deleted many of the text messages, it retrieved an entire exchange of messages between myself and someone, starting from October last year.
You can save the text messages out as a text file – so easily searchable. And save the voicemails out as MP4.
If you are engaged in some kind of dispute, negotiation or other action where you want to ensure you are maintaining robust records of communications I reckon $7.99 is a tiny price to pay. For a start would have thought lawyers should have this by default.
Not sure there's a Windoze version though for all of those people who have not converted to the alter of Jobs.
It's the little things that you learn that make life easier. I wanted to screenshot the RushCrowds iPhone app this morning, turns out is easy:
- Open the screen you want to copy
- Hold down the power and the home button at the same time for a second then release, the screen flashes white and you hear a camera click. (The power button, which might be officially called the sleep button I suspect, is the one at the top right, the home button is the round button at the bottom middle).
It saves the screenshots to your Photos, so you can email them, or just sync over to iPhoto.
I've been implementing a credit card payment gateway recently using the Cybersource system and their SIMPLE API features – it's a COM object based system.
Everything seemed to go swimmingly well until I struck a snag processing Refunds using the follow-on service, which is where you can refund a previous payment by referencing its unique identifiers. As opposed to a stand alone refund credit.
Cybersource steadfastly refused to allow the credit, giving me errors saying that I was missing a data field, which, after spending a bunch of time carefully checking the fields against their SDK documentation, I was convinced was not correct.
Finally I worked it out – and it had been staring at me in the face. Credit card systems generally have two modes:
- Authorization – where you check that the card number etc is valid, and that the customer has the bucks available
- Capture – where you then 'capture' the payment based on the Authorization
Virtually every credit card gateway I've used wraps Authorization and Capture into a single function for cases where you just want a straightforward payment. EG you just want to get the customer's money in a single transaction.
Cybersource is different, first you have to Authorize the payment, then Capture it, which of course you have to do as a single set of calls all as part of processing the customer's payment. On the surface of course it makes complete sense, you are replicating the actual process going on behind the scenes.
But in practice it means making two separate calls to the Cybersource API, all while the customer is sitting watching the spinning 'loading' icon in your shopping cart page.
Matters are not assisted by Cybersource's documentation not clearly describing this (a flow chart or diagram would be helpful), and their samples are woefully deficient – they don't actually have a sample that shows a combined Authorize and Capture scenario – which would surely have to be the single most common activity undetaken by developers implementing their API.
I really must share more interesting stuff as a I come across it.
I've been having fun recently using sp_OACreate in SQL stored procedures to use COM objects. For example, I came across this link that shows how to send email using the JMail COM object in a stored procedure.
A couple of helpful hints:
- You need to 'OLE Automation Procedures are enabled' as true, in SQL Surface Area Configuration
- You'll need a user with rights on the Master db. I created a separate user just for calling these stored procedures, and gave the them the following rights:
GRANT EXECUTE ON dbo.sp_OACreate TO [user]
GRANT EXECUTE ON dbo.sp_OASetProperty TO [user]
GRANT EXECUTE ON dbo.sp_OAMethod TO [user]
GRANT EXECUTE ON dbo.sp_OAGetErrorInfo TO [user]
My only problem so far is JMail won't send an attachment. I've tried messing with permissions on the file to be attached but that didn't help.