The TV stuff tends to be. The radio programmes are not. This is because one needs to pay a license fee in the UK to watch television, which funds the BBC. Listening to the radio is free, however.
US Postal makes money delivering marketing materials from local businesses (supermarkets and the like) to P.O. Boxes. They also offer no way to let you opt out of this.
I assume there's a list of valid PO boxes provided, much the way addresses are taken off of a list somewhere, addressed to "Current Resident", and delivered that way though the mail was not only obviously mass spam but not even addressed specifically to the resident.
Interestingly, nearly all ATMs (with the exception of privately-owned ATMs in bars, etc.) in the UK don't charge for services (for about five years now). However, I wonder whether an ATM owned by bank A charges bank B itself when bank B's customers withdraw cash at bank A's ATMs.
It depends entirely on how many people you're teaching. If you're sitting in a lecture hall full of 250 students, asking continual questions is just not going to get any response. No-one wants to embarass themselves in front of an audience that large. You'll just slow down the lecture while you pause and listen to a stony 10 second silence every couple of minutes. I've had lecturers do this, and it's extremely frustrating.
Personally, I don't mind lecturers "telling" the answers straight away. Obviously give motivation and lead into it rather than just delivering it with no introduction, but I've found a lot of problems are simply too large or too non-obvious to take a straw poll from the class.
The best teachers I've had have been:
(i) Really bloody good at their subject. My probability lecturer (the Field's medallist Tim Gowers), when presenting the proof of Stirling's approximation, said something along the lines of "now, the normal method for proving this bit is a bit complicated, and on my cycle in this morning I thought 'There must be an easier way', when the following struck me. Now, I've never written this down before, so hopefully it works...", and of course laid out a simplification of a famous proof that worked perfectly. Inspirational. (See http://gowers.wordpress.com/2008/02/01/removing-the-magic-fr...)
(ii) Incredible elucidators. The ability to take a complex concept and pick exactly the right words or metaphors to explain it is a powerful ability.
I feel these criteria are far more important than asking the audience questions. You need both -- I've been taught by plenty of talented mathematicians who had no idea how to teach, and certainly a handful of great teachers who simply didn't have the aptitude to really grasp the more complex topics.
Agree. Asking questions in a class of 250 students is counter productive. But, here in India, it's against regulations in many colleges to have classes larger than 60 students. So, perspective :)
taught 300 students in Kabul, Afghanistan at one go (English Class) - what we did was we had PowerPoint, we had a microphone (connected to a mixer and JBL speakers) - and everyone had a sheet so they can follow the lessons, even had think-pair-share (using the PowerPoint as prompts) - had 5 of these classes going at the same time in Kabul University and 1 at the Kabul Polytechnic simultaneously. So you could ask 300 students all at the same time if you set it up properly :)
"Also: The Emacs mouse support is not great. It probably hasn't been a high priority."
In what way? It's certainly as good as it is in any other editor, with the addition of several very Emacs-esque mouse-driven commands. For example, right click marks the region from point to the click point and saves it in the kill rin (like M-w); double right click kills that region. Using M- does the same, but modifies the secondary selection. Using C- with the mouse pops up several useful context menus. Try playing around with C-h k <mouse button> in various contexts.
Yes and no. When I first started off with Emacs, I used the CUA bindings (Windows-esque bindings for C-x/C-v/C-c). That was great to begin with, but inevitably a change of settings as big as CUA never quite sat right with the rest of Emacs, and prevented me from really moving on. After a while I declared cua-mode to be a crutch that was holding me back, disabled it, and I'm extremely glad I did.
More recently I've moved mostly away from the arrow-keys navigation (not just up/down/left/right instead of n/p/b/f but Home End instead of C-a, C-e; C-left, C-right instead of M-b, M-f; C-up, C-down instead of M-{, M-}; C-Home, C-End instead of M-< and M->, etc.) to the more central commands. This is less of a win but has nonetheless sped up my editing still further.
It's a great first step to hiring. But I'm surprised that he didn't have any university graduates pass--the problem itself is a freshman-level bozo test used to apply the concept of a stack. The rest (log in to ssh and install a CGI script) is a set of useful skills that any competent programmer could (hopefully) teach themselves within the timespan of the problem.
If you only have 3 out of 30 candidates pass the bozo test, that limits your choices when it comes to testing them on having any real talent.
As you and the original author both know, you don't need to use a stack data structure if you're just matching a single type of parens. (Your algorithm is the server-side solution employed by the author.) Though if you used {([])} with rules against them side-straddling like ([)], the stack would be necessary to distinguish what type of matching character you're using.
But look at what you have: an integer (n) that counts the number of unmatched open parens, that is not allowed to drop below 0, and that can only be incremented and decremented. Your solution there is essentially a pushdown automaton, with n representing your stack of open parentheses (and the value of n representing the size of the stack). If you approached the problem thinking of it as a stack problem, you'd probably end up optimizing to your solution when you realized that actually stacking parentheses could be efficiently simulated with an integer. But the restrictions you've placed on that integer effectively simulate the restrictions of pushing and popping parens off a stack. You're even going through the string once without backtracking.
I'm not sure if it's useful or just comp-sci wankery to think of it this way, but there's an equivalence between that solution and the freshman stack solution after all.
Which is interesting, as a proper regular expression is incapable of testing for a parens match. The set of strings with properly matched parens is a context-free language, not a regular language. But modern "regex" engines are capable of matching non-regular languages, and iterative regex-based substitutions (as his client-side code does--his server-side code is equivalent to the stack-based approach) can approximate the effect.
