With that in mind, I created a replacement method for UIDevice: UDID. It uses the device’s MAC address to generate a unique ID that is the same length as the old UDIDs. I was inspired by some other people’s solutions, but rolled my own implementation which I feel is neater, and more compatible (as it generates similar 40char UDIDs). You can fork it on github.

It’s not a drop-in replacement, for fear of monkey patching over an existing method. Just do a find & replace with: [[UIDevice currentDevice] UDID].

Of course: consider if device identifiers are right for you. To identify a specific install of your app (which can be migrated from one iPhone another due to loss/upgrading), generating a UUID and saving that as a NSUserDefault would work best (since it will transfer with the app data).

License: public domain.

The most awesome is KDiff3 (search for ‘Apple Mac OSX binary’ on that page for the Mac binary). This is a three-way merge tool with an editing panel below. Seriously where has this been all my life? Amazing.

Download it, and install – make sure it’s in your system PATH. Then simply run git config --global merge.tool kdiff3 to set it as your default merge tool. Now every time you get a conflict, your git mergetool command will actually be rather helpful! Basically you are shown the base revision (that both branches split from) in the middle, one branch either side, and an editor below allowing you to pick which side you want and/or edit the file directly.

The second tool I (re)discovered was SourceTree (Mac App Store DL Link). It is a Mac GUI client for git. I’m pretty comfortable with the command line, but what I love about this tool is it allows me to review my changes before I commit them (either staged or unstaged), discard hunks I don’t want, and of course open the file in question for editing. Very convenient. git diff is nice and all, but I love having that handy ‘discard hunk’ button in SourceTree so I can skip my silly changes. For me this is the most useful feature, though no doubt there are others. Oh and it’s free (it’s a bit confusing, as there is a “trial” period, but after the trial you simply register for free, and are given a license).

Refs:
1. Some useful git config tips
2. Graphical Diff Tools for Mac OS X
3. Setting up mergetool on windows

ActiveRecord::Base.connection.select_one('SELECT COUNT(*) FROM mytable')
ActiveRecord::Base.connection.execute('SELECT * FROM mytable')

Thanks revgeorge.

An iOS team is actually in two parts: the iOS Developer Team, accessed via the Member Center, and a completely separate iTunes Connect team.

It turns out that the one AppleID can belong to multiple iOS developer teams, and Apple asks you when you login to the member center which team you want to use. However iTunes Connect has no such feature, and each AppleID can only belong to one iTunes Connect “team”.

So you can re-use AppleIDs for developer accounts, but not itunes connect accounts. It’s up to you I guess if you want a totally separate AppleID for each team, or just each iTunes connect account.

I set it up with the help of this fantastic tutorial. My steps after the break.

Install

yum install monit

Configure on boot

/sbin/service chkconfig --levels 235 monit on

Create the config file

vi /etc/monit.d/monitrc

With something like:

set daemon 30
set logfile syslog facility log_daemon
set mailserver localhost
set mail-format { from: monit@www.example.com }
set alert you@example.com

check process sshd with pidfile /var/run/sshd.pid
start program "/etc/init.d/sshd start"
stop program "/etc/init.d/sshd stop"
if failed port 22 protocol ssh then restart
if 5 restarts within 5 cycles then timeout

check process apache with pidfile /var/run/httpd.pid
group www
start program = "/etc/init.d/httpd start"
stop program = "/etc/init.d/httpd stop"
if failed host www.example.com port 80 protocol http
and request "/monit/token" then restart
if cpu is greater than 60% for 2 cycles then alert
if cpu > 80% for 5 cycles then restart
if totalmem > 500 MB for 5 cycles then restart
if children > 250 then restart
if loadavg(5min) greater than 10 for 8 cycles then stop
if 3 restarts within 5 cycles then timeout

set daemon is used to specify the number of seconds between each check.

As per the docs, it is here.

Anything in single quotes is put through as-is.

Look no further than this awesome test app! Market link here.

Some high quality phone image marketing resources. I like this one.

How to do it in Javascript.

The token itself can be retrieved in Rails with: session[:_csrf_token]

I have all my dSYM files (I even use a build script that archives them all automatically), and spotlight can find them from the UDID, but to no avail.

The solution is atos.

I copied the dSYM file (actually a folder) to the desktop, and run this command & you will get the file & line of code. Repeat for each symbol in the crash that you need (generally you only need one or two key ones…)

$ atos -arch armv7 -o ~/Path/to/Your.app.dSYM/Contents/Resources/DWARF/AppName 0x000cefd8
 -[SomeClass someMethod] (in GeoLog) (AppName.m:242)

Thanks to NaveenShan for this tip.

Incidentally, If someone writes a Mac OS X app that can reliably symbolicate crashes, each time, every time, and doesn’t break on every new version of the SDK/OS – I will pay upwards of $50.

I wish things would just work, and I wouldn’t have to waste my precious dev time stuffing around with this crap.

iOS 5 changes this by splitting out the latter functionality to ‘presentingViewController’. Unfortunately, rather than creating 2 new methods with new functionality, they simply changed the old one and created the new one. So for anyone like me who missed this particular change (it’s not even in the API diffs as it’s not changed, or removed), [self parentViewController] starts returning nil, your code continus to run, but will probably hang if when you expect to have dismissed the view controller.

What terrible design. I think it would have been better to deprecated the old function & split it into two new ones. Or at least provide some warnings to the change. If Objective-C actually crashed on nil values like java, again this would be easy to spot & change – but hang bugs are particularly nasty to try and solve.

Anyway, here are my testing results of [self parentViewController] where self is a controller that was presented as modal:

XCode 4.1 & SDK 4.3: iOS 5: presentingViewController, iOS 4.x: presentingViewController
XCode 4.2 & SDK 5.0: iOS 5: nil, iOS 4.x: presentingViewController

As you can see, when iOS5 runs the older SDK it doesn’t break (because that would break everyone’s code), and iOS4 running with code from the new SDK doesn’t break either. Just SDK & iOS 5 together.

Fixing this if you only support iOS 5 is simple. Replace every instance of [self parentViewController] where you want the model view controllers parent to [self presentingViewController].

Most people need to support iOS 4. This is a bit of a pain because you can’t just call ‘presentingViewController’ without it crashing (due to this method not existing on iOS4). Here’s my #define to get the old behaviour back:

#define self_parentViewController (([self parentViewController] != nil || ![self respondsToSelector:@selector(presentingViewController)]) ? [self parentViewController] : [self presentingViewController])

In english, this means: if the parentViewController is not nil, or the presentingViewController method doesn’t exist yet (in the case of < iOS 5.0), return the result of presentingViewController. Else return the result of presentingViewController.

EDIT: if you need to call the old parentViewController on something other than self, try my revised #define.

NB. just like before – this *may* not return the presenting view controller, if self has it’s own parentViewController that isn’t the one which presented it. But this is equal to the old SDK behaviour, so I don’t think it will introduce bugs.

Everywhere in your code, replace [self parentViewController] with self_parentViewController (no square brackets).

#defines are normally pretty evil but in this case, until you drop 4.0 support I actually feel it’s cleaner. Now you could do [self parentViewController] || [self presentingViewController], and this will work in many cases, that is until parentViewController returns nil on iOS 4, when your app will crash due to the unrecognised ‘presentingViewController’ selector. Safter to use my #define for full backwards compatibility.

Pre iOS 5.0 docs:

parentViewController
The parent of the current view controller. (read-only)

@property(nonatomic, readonly) UIViewController *parentViewController
Discussion
Parent view controllers are relevant in navigation, tab bar, and modal view controller hierarchies. In each of these hierarchies, the parent is the object responsible for displaying the current view controller. If you are using a view controller as a standalone object—that is, not as part of a view controller hierarchy—the value in this property is nil.

Now it states (emphasis added)

parentViewController
The parent of the current view controller. (read-only)

@property(nonatomic, readonly) UIViewController *parentViewController
Discussion
Parent view controllers are relevant in navigation, tab bar, and modal view controller hierarchies. In each of these hierarchies, the parent is the object responsible for displaying the current view controller. If you are using a view controller as a standalone object—that is, not as part of a view controller hierarchy—the value in this property is nil.

Prior to iOS 5.0, if a view did not have a parent view controller and was being presented modally, the view controller that was presenting it would be returned. This is no longer the case. You can get the presenting view controller using the presentingViewController property.

Yet it still says it’s relevant in the ‘modal view controller hierarchies’, is it?

Also I love that modalViewController still says ‘see also: parentViewController’, there isn’t really a need for this now.

modalViewController
The controller for the active modal view—that is, the view that is temporarily displayed on top of the view managed by the receiver. (read-only)

@property(nonatomic, readonly) UIViewController *modalViewController
Discussion
Typically, a modal view is used to present an edit page or additional details of a model object. The modal view is optionally displayed using a vertical sheet transition.

Availability
Available in iOS 2.0 and later.
See Also
@property parentViewController
Declared In
UIViewController.h

Here’s the kicker in the docs. If you search for UIViewController and you have SDK 4.3 and 5.0 docs installed (common when you upgrade), you get multiple hits. If you pick the one that is the 5.0 sdk, then find the link to ‘parentViewController’. Clicking that link will open that method, but rather than scrolling down the page it will show it in the 4.3 docs! Without this warning. This makes this communication issue just that little bit worse.