Needed to mount a drive with the HFS+ file system (the one Mac OS X uses). It’s pretty easy. Ubuntu’s repos have a package called hfsplus.

sudo aptitude install hfsplus
sudo mount -t hfsplus /dev/sdf2 /home/username/folder

To unmount:

sudo umount -t hfsplus /dev/sdb2

Hooray — got myself a new body, the Canon 60D. I’d been wanting a 7D for a long time, but eventually, thanks to @theproof and a couple of other people, it turned out the 60D has the same internals as the 7D — same processor and same sensor. The 7D just has two processors, which only really affects burst-shooting speed and how many frames in a row it can manage. A few photos taken on the way home, below the cut.

The flip-out screen is, of course, a handy thing. You can also fold it inwards so it doesn’t get scratched in a bag. Phone snap:

Test shots (clickable):

Another post — to help things settle in my own head. About working with JSON in Objective-C, using parsing of tweets from Twitter’s public timeline as an example.

Out of the box Objective-C has nothing for working with data in JSON format. Only with XML. But there is a JSON framework, in case you’re forced into this by necessity / whim / your boss’s refusal to give you the data in XML (underline the relevant option). You can download it on GitHub. The latest version at the moment is 3.0.3. There’s also an alpha 3.1, but that’s an alpha.

The archive contains a Readme, examples, the framework itself, and some other files whose purpose is so far unknown to me :)

The framework files themselves live in the Classes folder, which is what you need to drag into the file list of your Xcode project. For convenience I renamed the folder to JSON after importing.

In RootViewController.h we import the framework with the line:

#import "SBJson.h"

In RootViewController.h we add the following code:

@interface RootViewController : UITableViewController  {
    NSMutableData *jsonData;
}
 
@property (nonatomic, retain) NSMutableData *jsonData;
 
@end

We declare a class property jsonData of type NSMutableData — that’s where we’ll stash the data returned by the request to the Twitter API.

The property line is needed in case we want to access the jsonData property from outside our class. nonatomic means that jsonData isn’t locked, i.e. we can both get and set the value. They write that nonatomic is faster than atomic. Atomic means we lock the value. About retain they say: How the setter method will set the variable. I haven’t fully figured out yet why this is needed and how to work with it, but without that line nothing works =).

We’ll grab JSON data from Twitter. Conveniently, the public timeline doesn’t require any auth or tokens — you just send a request to a particular URL, perfect for trying things out.

To start with — we have a class RootViewController. In RootViewController.m we’ll put the following code in viewDidLoad:

@synthesize jsonData;
 
- (void)viewDidLoad {
    [super viewDidLoad];
    // create an NSURL object with the address the request will go to
    NSURL *url = [ NSURL URLWithString: @"http://twitter.com/statuses/public_timeline.json" ];
 
    // create the NSURLRequest — the request itself
    NSURLRequest *theRequest=[NSURLRequest requestWithURL:url
                                              cachePolicy:NSURLRequestUseProtocolCachePolicy
                                          timeoutInterval:60.0];
    // start the connection
    NSURLConnection *theConnection=[[NSURLConnection alloc] initWithRequest:theRequest delegate:self];
    if (theConnection) {
        self.jsonData = [NSMutableData data];
    } else {
        NSLog(@"Connection failed");
    }
    [theConnection release];
}

To handle the connection and the data, you also need to add this code:

/**
 * As each new chunk of data arrives, append it to what we already have 
**/
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
    [jsonData appendData:data];
}
 
/**
 * If the connection fails — log the error to the console
**/
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error {
    NSLog(@"%@", error);
}
 
/**
 * Once all data has arrived — parse it 
**/
- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
    // store the received data into the result string
    NSString *result = [[NSString alloc] initWithData:jsonData encoding:NSUTF8StringEncoding];
	
    // we can log it to the console and inspect what we got
    NSLog( @"%@",result );

    // create the JSON parser object
    SBJsonParser *jsonParser = [[SBJsonParser alloc] init];

    // parse the result string into an NSArray
    NSArray *dataObject = [jsonParser objectWithString:result error:nil];

    // breakpoint can go here

    // don’t forget to free the objects
    [jsonParser release];
    [result release];
}

If you set a Breakpoint (CMD+\) at the spot indicated above (see «breakpoint can go here»), you can inspect the values at that point. The screenshot below shows that the string we received from Twitter was parsed into a dataObject of type NSArray, which contains 20 items inside it — i.e. data on 20 tweets from the public timeline.

After the breakpoint line, the received data can already be processed somehow. For example, you can log the received tweets to the console as «Username — TweetText»:

for ( NSDictionary *tweet in dataObject ) {
    NSLog(@"%@ - %@", [[tweet objectForKey:@"user"] objectForKey:@"screen_name"], [tweet objectForKey:@"text"] );
}

Hopefully I haven’t lied or got anything wrong anywhere. Corrections / clarifications very welcome.

Why not pin this here — easier to find later, when I need it again. Search engines often treat pages like

arm1.ru/blog/yandex-upal-panika-v-twitter

and

arm1.ru/blog/yandex-upal-panika-v-twitter/

as different pages. So you end up with the same content technically living at two URLs, which isn’t great. Below the cut — code that automatically strips a trailing / via a 301 redirect, so search engines don’t end up with duplicate pages.

<?php

# strip the QUERY_STRING from REQUEST_URI
$uri = $_SERVER['REQUEST_URI'];
if ( false === empty( $_SERVER['QUERY_STRING'] ) )
    $uri = str_replace( '?' . $_SERVER['QUERY_STRING'], '', $uri );
			
# 301 redirect when there is a trailing slash on $uri
if ( substr( $uri, -1 ) == '/' && strlen( $uri ) > 1 ) {
    $queryString = '';
    if ( false === empty( $_SERVER['QUERY_STRING'] ) )
        $queryString = '?' . $_SERVER['QUERY_STRING'];
 
    header( 'Location: ' . substr( $uri, 0, -1 ) . $queryString, true, 301 );
    exit;
}

Went to Apple Developers Community #7 today. The talks were about marketing iOS apps. Two people effectively presented — a representative from Nevosoft, who seem to crank out games on a conveyor belt, and one indie developer.

It was pretty boring. What they said could have been said much faster. The woman from Nevosoft was asked silly questions for ages. As always, there were a couple of know-it-alls in the room itching to demonstrate how clever they were.

Not that there were any revelations, but a lot of things, until someone says them out loud, don’t feel important and don’t stay in your focus.

Key takeaways. The app icon is very important. Insanely important (I’m not being sarcastic) — the first thing the user sees is the icon in the listing. It should be bright; the advice was to take a screenshot of the App Store, drop your icon into it, and check whether it stands out and catches the eye. Plus look at how it looks on the iPhone home screen among other apps — the user should be able to spot it visually quickly.

The second thing the user sees is the app screenshots. How they look matters too — they need attention. If they don’t hook the user, they won’t install your app even if it’s free (from my own experience — agreed). The view was that doing plain app screenshots isn’t always worth it — they look much more appealing if presented somehow, e.g. composited inside an iPhone mock-up. Apple doesn’t require screenshots to be strictly app screenshots, and many people exploit this, building entire collages.

On launch day you get a head start by appearing in the «New» list within your category. So later sales/downloads largely depend on the first day.

Then they talked about the description and choosing keywords. People usually try to pick keywords cleverly so that fewer competitors show up for them and you get noticed. It’s a double-edged sword — you can find a word for which you’re alone, but no one would think to type it. The indie developer claimed that if a keyword appears both in your app name and in the keyword list, you rank higher. That’s his personal experience.

Worth investing in the description too — if people read it at all, they read at most the first lines. Walls of text discourage further reading (again, agreed from experience).

Apple requires apps to have a website / web page. It’s a mandatory condition so users have a way to give feedback to the developer. And again — to a degree it generates user flow.

Then they discussed various ad networks, click-throughs, and the pros and cons of Full and Lite versions — also a double-edged sword. On one hand, Lite drives traffic to the Full version. On the other, promoting two apps is harder than one.

The indie developer said you have to polish everything — do every possible localisation (he commissioned translations into European and Asian languages), and each new localisation brought him a percentage of new users. Work properly on press releases, especially in other languages, even outsourcing them to specialists for proofreading.

And, most importantly — the app shouldn’t be crap, but that one’s obvious.

Long meant to share my modest set of functions for posting tweets to Twitter. Maybe useful to someone — none of it came to me right away, especially the signature generation. Plus this is my attempt to lock into my head what I’ve learnt and coded. The best way to do that, I think, is to try to explain it to someone else :) Description and code below the cut.

There are quite a few scripts online for posting messages to Twitter, but when I had to set up automatic tweeting (for work) — none of them quite did it for me, either because of unnecessary complexity or just outright spaghetti code. On top of that, while learning the Twitter API, writing my own bicycle was useful in itself.

Communication with the Twitter API happens via OAuth authorisation (specifically OAuth, not OAuth 2.0 — though maybe 2.0 is fine by now). Requests have to be assembled in a particular way and accompanied by a specially crafted signature.

First, register an app at dev.twitter.com; you’ll get a Consumer key and Consumer secret. They’ll also issue you personally an Access token and Access token secret, so the app can post on behalf of your user right away.

Let’s define the access settings for the script:

# settings
$oauth_token = 'Your access token';
$oauth_token_secret = 'Your access token secret';
$oauth_consumer_key = 'Your consumer key';
$oauth_consumer_secret = 'Your consumer secret';
$url = 'http://api.twitter.com/1/statuses/update.json';

In my case posting a tweet consists of 4 steps:

1. Building the tweet text (a 140-character string with text and possibly a link).
2. Building the request parameters and signature.
3. Building the request headers.
4. Sending the request.

The set itself consists of 3 functions. The main function is postTweet(). It takes the tweet text as a parameter — pre-prepared, i.e. already 140 characters long. Usually I prepare it somewhere outside of this function. Inside postTweet, the other 2 functions are called — the signature builder (makeSignature) and the actual function that posts the tweet to Twitter (postTweet).

Let’s go in order. The signature function makeSignature:

/**
* Builds a signature for the data
* @global array $oauth_consumer_secret
* @global string $oauth_token_secret
* @param string $url
* @param Array $data
* @return string
*/
function makeSignature( $url, $data ){
  global $oauth_consumer_secret, $oauth_token_secret;

  $txt = 'POST&' . rawurlencode( $url ) . '&';

  $tmp = array();
  foreach( $data as $key => $value )
    $tmp[] = rawurlencode( $key ) . "%3D" . rawurlencode( $value );

    $txt .= implode( "%26", $tmp );

    $key = $oauth_consumer_secret . '&' . $oauth_token_secret ;

    return base64_encode( hash_hmac( 'sha1', $txt, $key, true ) ) ;
  }

As input, the function takes the data needed to build the signature ($data) and the $url the request will go to. In short — we build a string. First we write POST in it, indicating we’ll use a POST request. The input parameters are assembled into the right form (alphabetical order matters), then this whole thing is encoded with the HMAC-SHA1 algorithm; the encoding key is:

$key = $oauth_consumer_secret . '&' . $oauth_token_secret;

The encoded string is our signature. This deceptively simple function ate up a fair bit of time and nerves =(

Now the main function — postTweet:

/**
* Posts a message to Twitter
* @global string $url
* @param string $oauth_consumer_key
* @param string $oauth_token
* @param string $statusText
*/
function postTweet( $statusText ){
  global $url, $oauth_consumer_key, $oauth_token;

  $nonce = md5( microtime() . mt_rand() );
  $time = time();
  $date = date( 'r' );

  $data = array(
    'oauth_consumer_key' => $oauth_consumer_key,
    'oauth_nonce' => $nonce,
    'oauth_signature_method' => "HMAC-SHA1",
    'oauth_timestamp' => $time,
    'oauth_token' => $oauth_token,
    'oauth_version' => '1.0',
    'status' => rawurlencode( $statusText )
  );

  $signature = makeSignature( $url, $data );

  $data['status'] = $statusText;
  $data['oauth_signature'] = $signature;

  $header = 'OAuth oauth_nonce="' . rawurlencode( $nonce ) . '", ';
  $header .= 'oauth_signature_method="HMAC-SHA1", ';
  $header .= 'oauth_timestamp="' . rawurlencode( $time ) . '", ';
  $header .= 'oauth_consumer_key="' . rawurlencode( $oauth_consumer_key ) . '", ';
  $header .= 'oauth_token="' . rawurlencode( $oauth_token ) . '", ';
  $header .= 'oauth_signature="' . rawurlencode( $signature ) . '", ';
  $header .= 'oauth_version="1.0"';

  return curlPostTweet( $url, $header, $date, $data );
}

This function takes the already-prepared tweet text (140 characters), and the $data array is filled with request data. Then the request signature is built from the same data (calling makeSignature, described above). The signature is added to the data. The HTTP request headers are built — basically the literal string "OAuth" followed by the same $data values. All of that is then passed to curlPostTweet(), which actually posts to Twitter. It does so via CURL.

function curlPostTweet( $url, $header, $date, $postData ){
  $ci = curl_init();

  curl_setopt( $ci, CURLOPT_URL, $url );
  curl_setopt( $ci, CURLOPT_RETURNTRANSFER, true );
  curl_setopt( $ci, CURLOPT_HTTPHEADER, array( 'Authorization', $header, 'Date: ' . $date ) );
  curl_setopt( $ci, CURLOPT_POST, 1 );
  curl_setopt( $ci, CURLOPT_POSTFIELDS, http_build_query( $postData ) );

  return curl_exec( $ci );
}

I don’t think this needs further explanation. You can also inspect the result the request returns. If something’s wrong, it’ll contain an error and its description. Otherwise the request returns the freshly posted tweet and info about it. And in your timeline, the freshly posted tweet will proudly show as its client the name of the app you registered.

As a bonus, I’m attaching a function for getting a shortened link. Here it uses the clck.ru link shortener by @bobuk

function curlGetShortLink( $url ){
  $link = "http://clck.ru/--?url=" . $url;

  $ci = curl_init();

  curl_setopt( $ci, CURLOPT_URL, $link );
  curl_setopt( $ci, CURLOPT_RETURNTRANSFER, true );

  while ( true ) {
    $returned = curl_exec( $ci );
    $status = curl_getinfo( $ci, CURLINFO_HTTP_CODE );

    # if the service is unavailable or rate-limited:
    if ( $status == "200" ) {
      break;
    }

    sleep( 2 );
  }

  return $returned;
}

These functions currently power 4 bots, which have been doing their job for several months now. If you’re curious — @funkysouls and @rutracker_ios, which parse RSS and post to Twitter, plus a couple of our work bots.

Thanks to @stay_positive for the timely help — and some of the code here is his. Oh and