The weekend was spoiled by my MacBook Pro: it had gone to sleep at the office, woke up at home, and a few seconds later froze solid. Had to do a hard reset.

The OS refused to boot — neither from the main partition nor from the Recovery HD partition that OS X Lion creates for restoring/reinstalling the system. Although the MacBook could see both partitions. I managed to boot from a USB stick.

My first thought was something wrong with the hard drive — either partitions had detached or the disk was dying. I pulled the drive, hooked it up to my second Mac via a USB enclosure. All files in place, no signs of trouble. OK, I figured, time to reinstall macOS from scratch — looked like a software glitch, those upgrade-from-previous-version updates can be flaky.

Backed up everything, ran Disk Utility’s repair, it fixed something I didn’t understand. Stuck the drive back in — decided to try booting from it — and lo and behold, everything worked. I breathed a sigh of relief, shut down, started up, slept the laptop, woke it — all fine.

It sat quietly until the next evening. I opened it — and the same thing happens — freezes and won’t boot any more. Booting in verbose mode (CMD+V at startup shows the boot log on screen instead of just the apple on a grey background) showed me some unfamiliar errors, clearly disk-related — the system couldn’t mount one of the partitions. This time it wouldn’t even boot from the USB stick. I pulled the drive again, wiped all partitions — no good. Stuck in a different drive — and that’s when it turned out that one was sometimes invisible too. Annoyed, I drove to the service centre, by then almost certain the problem was with the cable.

That’s exactly what it was — they swapped the cable, charged me 2,500 roubles. They ran my MacBook through their tests — the rest of the hardware is fine.

Investigating the cause of the cable damage is unlikely to be possible. But the cable looks very strange.

On top — the new one, freshly installed. Below — the old one, all marked up. The cable itself is quite thin, and those pinpoint dents could easily have broken contacts inside it. What’s strange — the same dents are on the optical drive, and in a few other places. And all of this is inside the case.

Another shot of the old cable

The cable runs through the case the way you can see in the photo above (the hard drive lives bottom-left), with the case lid sitting on top.

The only theory I have for what could have happened: sand got inside, kept shifting around in there and getting pressed when the laptop was being carried in a backpack. In principle it could have got in in Vietnam, where I spent a month and occasionally got the laptop out on the beach — and on that beach there’s usually a strong wind (kite-surfers come there for a reason), with sand constantly in the air. But that was a year and a half ago — why the problem only showed up now, and where the hell all the sand has gone, given that it was inside a closed case, is still a mystery.

Now I need to give the laptop’s insides a proper cleaning, in case anything’s still in there. And tape over that cable with something. They suggested heat-resistant tape, the kind that doesn’t mind temperature. Just to put a layer between the cable and the case lid, so that if anything gets in again, it scratches the layer rather than the cable. Maybe a thin foam strip would work too — we’ll see when I get to it. Sand is evil.

By the way, this cable plugs into the motherboard with this odd-looking thing:

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.