You want to return a block from an OCMock stub method, something like this :

```
```

```
[[[the_mock stub] andReturn:the_block] method];
```

```
```

That should work, right ? According to the blocks docs :

Blocks are Objective-C objects, which means they can be added to collections like NSArray or NSDictionary.

But it doesn’t work, and OCMock throws you an exception along the lines of `Expected invocation with object return type. Did you mean to use andReturnValue: instead?`

I’m coding an ObjC application that I want to do a number of things in parallel using a GCD dispatch queue, but I want to limit the maximum number of tasks that can be running on the dispatch queue at any one time. Mainly because the tasks are going to be hitting up someone else’s web server pretty damn hard and I want to be able to throttle it to some reasonable number so as not to be rude.

So I coded up a quick spike using the Muppets (well, one Muppet) as an example before I dive in head first….

After having much success hacking myself up a wheel zoom extension for Safari – now available as an open source project on GitHub – I decided to port the code over to a Chrome extension as well…

If you have an Apple laptop of some kind, or you use a magic mouse or trackpad on the desktop, you can use gestures to zoom in and out of web pages in Safari.

If, on the other hand, you have some kind of non standard setup – I use a hefty MS Sidewinder multi button mouse and a Saitek Cyborg illuminated keyboard jacked into a Mac Mini, for example – your zoom option is : you can press [command] and [+].

But I missed my zoom wheel, so I stuck with Chrome until the flakiness of the wheel zoom add on I was using made me stabby and I finally sat down and figured out how to hack mouse wheel zoom into a Safari extension.

For some reason, I often find myself getting tangled up with UIViews. A sure sign that I need to spend some time getting my head around their conceptual framework.

One thing that keeps tripping me up is that I start off by doing loads of setup in the `viewDidLoad`

method of the root `UIViewController`

, and it turns out that this is spectacularly bad practice.

One thing I find myself doing on a fairly regular basis is looking for a list of the various iOS device screen resolutions. I’m actually 100% sure that I’ve seen one in the Apple docs somewhere, but I’m buggered if I can find it again.

So naturally I end up googling, but the hits that come up top on google aren’t massively helpful. Hopefully, this will percolate its way up the SEO rankings and be of help. Probably just in time for it become obsolete.

I’ll keep it updated when new hardware arrives, in the mean time, if you’re reading this and spot and error or omission, please do leave a comment so I can fix it.

Embedded Gist missing scrollbar ? Using bootstrap or similar ? You’ll kick yourself. Bootstrap et al set CSS `whitespace: wrap;`

to keep text inside the columns, and your embedded gist inherited it. Now it has no horizontal scrollbar and the text is wrapping around. This looks particularly hideous on mobile. Fortunately, the fix is easy peasy.

You just need to do this in your stylesheet :

```
```

```
.gist .line {
white-space:pre;
}
```

```
```

And the Gist takes care of of sorting out its scrollbars and not overflowing the boundaries of the column.

After building a simple web service endpoint using webpy, I posed myself the question : “How much Objective C code would we need to write in order to get a minimally functional web server up and running and provide a basic framework in the same fashion as webpy does ?”

As it turns out,building a minimal HTTP Server (or web service) from (almost) scratch for OS X or iOS using Objective C is reasonably straightforward using Grand Central Dispatch (GCD).

When I started building this site, I decided to keep my UI really minimal so as to keep focus on the content. But you have to leave some navigational hints, or it is easy to become disorientated. To fit in with the sort of minimalist 'style' I chose a simple - but hopefully still obvious - highlight whereby the section of the siite you are currently looking at is highlighted in a darker color in the navigation menus.

I also extended this to the blog section, adding the same highlight rules to categories. This is made easy by the `wp_list_categories()`

function which helpfully adds a css class, `current-cat`

, to the currently selected category (if any).

I wanted to extend this to both archive and tag links, however the `wp_get_archives()`

function doesn't support this, and there isn't (AFAIK) a `wp_list_tags()`

function at the time of wrting.

There's an interesting workaround for `wp_get_archives()`

on the wordpress support forums here which did the trick quite nicely.

That still left me with a lack of `wp_list_tags()`

though, so I put on my PHP hat and knocked one up. It shares, via the underlying `get_tags()`

function, a subset of option parameters with `wp_list_categories()`

, and I added a 'show_count'. See the codex dox on `get_tags()`

for a full list of options.

It doesn't currently share the bounteous crop of $arg parameters enjoyed by wp_list_categories(), but it certainly plugged my particular gap. To use this code, you need to insert it into your theme's `functions.php`

file.

'Simple' as in it's a simple script, and also 'simple' in the sense of it won't work for anything that isn't simple. I have encountered a gloriously diverse range of weird and wonderous things in CSV like format over the years that would confuse this code.

Python has a pretty decent CSV module for when you encounter a big data set dumped by a careless MS Access programmer, but I used this very simple script to generate tables from a very simple ASCII CSV spreadsheet dump that had no issues with quoting, etc.

Published in the hope that someone may find it helpful.

Often, on the various codemonkey forums and websites you'll come accross when googling around PHP session security, you see people doing some really weird ass things in php session auth code that everyone seems to accept is useful, but often possibly isn't.

In particular, 'fingerprinting' a session by checking against a browser's User Agent String. This seems to be fairly pointless. Also the checking of the user's IP address, this also seems to be somewhat questionable.

There appear to be, broadly speaking, two types of attacks that can compromise PHP session security. Well, two that people get hot under the collar about, anyway. Session fixation, where the attacker is able to supply, force or guess a user's session ID, and session hijacking where an attacker is able to compromise the session ID by some other means.

Session fixation attacks, as a class, can be foiled by regenerating the session ID when a user authenticates, so in these situations, checking the User Agent/IP is redundant, as the attacker's supplied session is no longer valid.

Then there's session hijacking. This is trickier. For a network based hijack, the attacker has access to the User Agent string, and is, in all likelyhood either presenting as from the same IP address (behind the same router) or is able to pretend to be using TCP/IP spoofing, redirection, packet rewriting, or some other ~~nifty trick~~ evil hack. This is inherent in the access required to peform network based hijacking, be it sniffing or MITM attacks. The only mitigation for this is to never send a cookie or other form of session identifier over an unsecured link.

So, for either of the above scenarios, checking the User Agent/IP is either entirely redundant, or almost entirely worthless. I say 'almost', because it is just barely possible that some class of very amateur attacker executing a sniffing based attack will hit a speed bump while they figure out the User Agent might be being checked, but about ten seconds worth of googling will get them past it.

There is, however, a further scenario which is likely to be of concern to many PHP developers, which is having session IDs stolen by malicious actors on shared hosting platforms.

By default, PHP writes its session data to whatever is the local equivalent of /tmp. My current OS X web development box is using /var/tmp and my web host is using /tmp.

PHP ession data is stored in files with long hard to read names, something like `sess_g23hhjh5rrce3laeuib8t5utl3`

where `'g23hhjh5rrce3laeuib8t5utl3'`

is the session ID as stored in the cookie on the user's browser.

It is therefore entirely conceivable that either a malicious or compromised account on the same server can obtain your session info.

If you're on a shared host, you can clearly see this situation by running the following PHP code on your server. You probably shouldn't, but you can.

In this scenario, a session ID can be stolen by someone who doesn't have access to the user's User Agent string, unless it is stored in the session. If it is stored in the session, but is hashed, it is computationally relatively trivial to run a dictionary attack since User Agents are finite and predictable.

There seems to be a folk belief among programmers that salting the stored hash will prevent this attack, this is unlikely, even if you *are* doing it right because salted hashes are a defence against rainbow table based attacks, not dictionary ones. No amount of salt will help you cope with a trivial dictionary space.

Checking the UA in this scenario *might* be helpful, because if you check every `GET/POST`

and deauthorise the session on a mismatch, the dictionary attack is thwarted. Unless it gets lucky the first time. The probability of this is going to be a function of the number of user sessions and the distribution of UA strings, I haven't done the math, but it should be fairly obvious that the more users you have, and the fewer browsers they are using, the higher the probability is of scoring a hit.

It should also be fairly obvious that deauthing your users based on a single incorrect user agent string is a pretty good way of allowing an attacker to DoS your entire user base. The relative risk and cost of this is going to depend what you're doing, and what your options for mitigation are (we'll get to that in a moment).

This is akin to the classic asymetrical warfare scenario, in that the attacker only has to get lucky once to compromise your site, and has multiple opportunities to be so, but your defensive strategy relies on the attacker never being lucky at all. And while the attacker is not being lucky, they are still able to cause widespread disruption.

That leaves us with the IP address. In this scenario, checking the IP address presents a barrier to the attacker provided that she is located behind a different router to the intended victim(s). While this is certainly possible, perhaps even likely, it is certainly possible to imagine scenarios where it isn't; large university and corporate campuses, and mobile networks come to mind.

Checking the IP also has several drawbacks. Firstly, it breaks the stateless model of http, and in so doing, creates an abstraction leak between protocol layers. HTTP is an application layer protocol and it isn't supposed care about the transport layer at all, and it certainly isn't supposed to care about any state therein. This may seem trivial, and once upon a time it may very well have been so, but it isn't, and it increasinlgy won't be.

Expecting a user's IP address to remain constant over the course of a session is somewhat wishful thinking. Mobile users, for instance, may be skipping from WiFi hotspot to wifi hotspot via brief sojurns on 3G mobile networks using load balancing proxy servers, for instance. That's a whole heap of possible stuff that your web app needs not care about if you don't want to keep reauthenticating your users every time the state of the underlying network changes.

Fortunately, this entire class of attacks can be mitigated by storing your session information somewhere else. Somewhere that isn't world readable. Whether or not you have some space that is not world readable is dependent on the configuration of the host you're working with, it should be fairly obvious that having such is very much the lower bound for providing any kind of session security.

Exercise 1.13 is really interesting, for 'break out the algebra, oooh Fibonacci!' values of interesting, anyway. I had loads of fun with this, having only a passing awareness of the Fibonacci numbers. By the time I had satisfied myself that I understood the question and could venture an answer of my own, I had been on a fascinating journey through the mathematics of Fibonacci numbers and the Golden Ratio. Anyway, on with the exercise.

Prove that \(Fib(n)\) is the closest integer to \(\phi^n / \sqrt{5}\), where \(\phi = (1+\sqrt{5})/2\).

Hint: Let \(\psi = (1-\sqrt{5})/2\). Use induction and the definition of the Fibbonaci numbers (see section 1.22) to prove that \(Fib(n) = (\phi^n - \psi^n)/\sqrt{5}\).

Here's the given definition of the Fib function :

$$Fib(n) = \begin{cases}

0 & n = 0\\

1 & n = 1\\

Fib(n-1) + Fib(n-2) & \text{otherwise}

\end{cases}$$

We're also given \(\phi = \frac{\left(1 + \sqrt{5} \right)}{ 2 } \approx 1.6180\) and \(\phi^2 = \phi + 1 \).

We'll start by proving out the theorem from the hint, and see where we get.

**Theorem 1.**

$$Fib(n) = \frac{ \phi^n - \psi^n }{\sqrt{5}}$$

**Base Cases.**

$$\begin{align*} Fib(0) = 0 = \frac{ \phi^0 - \psi^0 }{ \sqrt{ 5 } } = \frac{ 1 - 1}{ \sqrt{5} } = 0 \\

Fib(1) = 1 = \frac{ \phi^1 - \psi^1 }{ \sqrt{ 5 } } = \frac{ \phi - \psi }{ \sqrt { 5 } } = \frac{ \sqrt{5} }{ \sqrt{ 5 } } = 1 \end{align*} $$

**Induction Step.**

There are a couple of ways to approach this step, probably the single simplest is to note that both \(\phi\) and \(\psi\) have powers that satisfy the Fibonacci recurrence, which is to say that :

$$\phi^n = \phi^{n-1} + \phi^{n-2}$$ $$\psi^n = \psi^{n-1} + \psi^{n-2}$$

Taking that as a given we can simply do this :

$$\begin{align*} Fib(n-1) + Fib(n-2) = \frac{ \left( \phi^{n-1} - \psi^{n-1} \right) + \left( \phi^{n-2} - \psi^{n-2} \right)}{\sqrt{5}} \\

= \frac{ \left( \phi^{n-1} + \phi^{n-2} \right) - \left(\psi^{n-1} + \psi^{n-2} \right) }{\sqrt{5}} \\

= \frac{\phi^n - \psi^n}{\sqrt{5}} \quad \quad \square \end{align*}$$

Neat, huh ? "But wait!", I hear you cry, "That's a very short proof and everything, especially given the lengths of some answers to this exercise, but it rests on an assertion you got off Wikipedia and haven't proved! That's cheating!"

And you've got me there. To get to Q.E.D without relying on the assertion, we note that the Golden Ratio has the property \(\phi^2 = \phi + 1\) given in section 1.22 and we note that \(\psi^2 = \psi + 1\) is also the case because they're the postive and negative roots of the polynomial \(\phi^2 - \phi - 1 = 0\). Given which, we can do an induction thusly :

$$\begin{align*} Fib(n-1) + Fib(n-2) = \frac{ \left( \phi^{n-1} - \psi^{n-1} \right) + \left( \phi^{n-2} - \psi^{n-2} \right)}{\sqrt{5}} \\

= \frac{ \left( \phi^{n-1} + \phi^{n-2} \right) - \left(\psi^{n-1} + \psi^{n-2} \right) }{\sqrt{5}} \\

= \frac{ \left[\left(\phi+1\right)\phi^{n-2}\right] - \left[ \left(\psi+1\right)\psi^{n-2} \right]}{\sqrt{5}} \\

= \frac{ \left[\left(\phi^2\right)\phi^{n-2}\right] - \left[ \left(\psi^2\right)\psi^{n-2} \right]}{\sqrt{5}}\\

= \frac{\phi^n - \psi^n}{\sqrt{5}} \quad \quad \square \end{align*}$$

Not only does that get us to Q.E.D without relying on an unproven assertion about reccurrence raltions, it also *actually proves* the relation. Well, at any rate, the proofs drop out of it :

$$\phi^n = \phi^{n-1} + \phi^{n-2} = \left(\phi+1\right )\phi^{n-2} = \left(\phi^2\right)\phi^{n-2} = \phi^n\\

\psi^n = \psi^{n-1} + \psi^{n-2} = \left(\psi+1\right )\psi^{n-2} = \left(\psi^2\right)\psi^{n-2} = \psi^n$$

Smashing. We've proved three things before breakfast and we're not even done yet.

Since we now know that is the case that

$$Fib(n) = \frac{ \phi^n - \psi^n }{\sqrt{5}}$$

We can state that the relationship between \(Fib(n)\) and \(\phi^n / \sqrt{5}\) looks like this :

$$ \left| Fib(n) \quad - \quad \frac{\phi^n}{\sqrt{5}} \right| \quad = \quad \left| \frac{ \psi^n }{ \sqrt{5}} \right| $$

Clearly as \(n\) gets really big, \(\psi^n\) is going to get really small, so \(\phi^n/\sqrt{5}\) is definitely a good approximation to \(Fib(n)\), but what about the "closest integer" ? How are we to define that ? Let's throw caution to the wind and decide that it means

**Theorem 2.**

$$\left| Fib(n) \quad - \quad \frac{\phi^n}{\sqrt{5}} \right| \quad = \quad \left| \frac{ \psi^n }{ \sqrt{5}} \right| \quad \lt \quad \frac{1}{2}$$

Because if we used \(\leq\) we could have two equidistant integers, and that doesn't fulfil "closest". Can we stand that up ? Let's look at some values :

\(n\) | \(\psi^n\) | \(\left|\frac{\psi^n }{\sqrt{5}} \right|\) |

\(0\) | \(1\) | \(0.44721...\) |

\(1\) | \(\psi\) | \(0.27639...\) |

\(...\) | \(...\) | \(...\) |

Excellent, \(\left|\frac{\psi^n }{\sqrt{5}} \right|\) starts out \(\lt \frac{1}{2}\), and it isn't going to get any bigger.

So yes, since \(\left|\frac{\psi^n }{\sqrt{5}} \right| \lt \frac{1}{2}\) for \(n \geq 0\) it follows that \(Fib(n)\) is indeed the closest integer to \( \frac{ \phi^n}{\sqrt{5}} \quad \square\).

However, since we've proved that, but not tested it, how about some code to look at the numbers ?

And some results^{*} :

\(n\) | (fib n) | (golden-fib n) | (closed-fib n) | (psi-n-root-5 n) |

\( 0 \) | \( 0 \) | \( 0.4472135955 \) | \( 0.0 \) | \( 0.4472135955 \) |

\( 1 \) | \( 1 \) | \( 0.72360679775 \) | \( 1.0 \) | \( 0.27639320225 \) |

\( 2 \) | \( 1 \) | \( 1.17082039325 \) | \( 1.0 \) | \( 0.17082039325 \) |

\( 3 \) | \( 2 \) | \( 1.894427191 \) | \( 2.0 \) | \( 0.105572809 \) |

\( 4 \) | \( 3 \) | \( 3.06524758425 \) | \( 3.0 \) | \( 0.0652475842499 \) |

\( 5 \) | \( 5 \) | \( 4.95967477525 \) | \( 5.0 \) | \( 0.0403252247502 \) |

\( 6 \) | \( 8 \) | \( 8.0249223595 \) | \( 8.0 \) | \( 0.0249223594996 \) |

\( 7 \) | \( 13 \) | \( 12.9845971347 \) | \( 13.0 \) | \( 0.0154028652506 \) |

\( 8 \) | \( 21 \) | \( 21.0095194942 \) | \( 21.0 \) | \( 0.00951949424901 \) |

\( 9 \) | \( 34 \) | \( 33.994116629 \) | \( 34.0 \) | \( 0.0058833710016 \) |

\( 10 \) | \( 55 \) | \( 55.0036361232 \) | \( 55.0 \) | \( 0.00363612324741 \) |

\( 11 \) | \( 89 \) | \( 88.9977527522 \) | \( 89.0 \) | \( 0.00224724775419 \) |

\( 12 \) | \( 144 \) | \( 144.001388875 \) | \( 144.0 \) | \( 0.00138887549323 \) |

\( 13 \) | \( 233 \) | \( 232.999141628 \) | \( 233.0 \) | \( 0.000858372260957 \) |

\( 14 \) | \( 377 \) | \( 377.000530503 \) | \( 377.0 \) | \( 0.000530503232271 \) |

\( 15 \) | \( 610 \) | \( 609.999672131 \) | \( 610.0 \) | \( 0.000327869028685 \) |

\( 16 \) | \( 987 \) | \( 987.000202634 \) | \( 987.0 \) | \( 0.000202634203586 \) |

\( 17 \) | \( 1597 \) | \( 1596.99987477 \) | \( 1597.0 \) | \( 0.000125234825099 \) |

\( 18 \) | \( 2584 \) | \( 2584.0000774 \) | \( 2584.0 \) | \( 7.73993784866e-05 \) |

\( 19 \) | \( 4181 \) | \( 4180.99995216 \) | \( 4181.0 \) | \( 4.78354466128e-05 \) |

^{*} I actually used a python script to generate the above table. as I haven't got quite so handy with Scheme yet and I was too lazy to type all the table HTML, but the results are within a seriously insignificant distance of one another, on the order of .00000000002 or thereabouts. |