The Art of Overtaking
April 18, 2014
Overtaking a race car is harder than it looks, the car in front will always be on the fastest part of the track, you have to overtake by driving past on a slower line. Unless you're a lot faster, it wont work. Instead, better to pressure your oponent into making a mistake.
First, follow the car in front, study their driving style and wait for your chance. I followed this close for several laps:
And discovered he drives slower than me through the first corner on each lap.
I make my move, shifting to the wrong side of the track right when I know he's going to brake, just after the 4 sign like he did every every earlier lap:
And I brake extremely late, at the 2 sign even though I'd really need to brake around the 3 sign to get through the corner properly:
Braking late gets me in front easily, but my entry to the corner is messed up, and I miss the apex by a mile:
Instead of fighting for my position, which would likely cause a crash, I brake at the last moment and let my oponent past:
And I'm behind him again, but now he's nervous. He was ahead of me comfortably for many laps then almost crashed twice in a span of a few seconds. I was expecting the risky manouver but he wasn't.
And it shows, he barely makes the next corner, look closely you can see his back wheels sliding out slightly, on a knife edge of spinning out of control:
He made the corner, but it slowed him up and I'm on his tail again a few seconds later:
Now is the time to pounce, I head over to the other side of the track again, ready to try my previous overtaking manouver again:
This time I'm too far back to get past, and this is a part of the track where he typically drives faster than me. But he's under pressure and expects me to brake as late as possible again. Instead I brake early:
And he brakes as late as possible:
That's how you overtake a race car.
April 12, 2014
Brent Simmons points out, in this blog post, that much of programming is just navigating around, which is only well supported in IDEs, not Text Editors, and even IDEs only get it right with languages that are structured to allow for it (eg: C# works great, PHP not so great, Obj-C is in between).
My solution, as someone who built my own text editor, is to have really good search. In particular:
Search should be fast
Even on an SSD equiped mac, TextMate beachballs for a long time when searching
250,000 files (totalling 3GB) for the search term "b". My app finishes searching
in 10 seconds, and shows the first several thousand results within a millisecond
of releasing your key from the keyboard.
With a moderate search, say 8,000 files and 250MB, TextMate takes 13 seconds and
my editor barely even blinks a
UIProgressView onto the screen before hiding it again, the search is finished faster than you can type.
It does this using a pretty innovative Grand Central Dispatch based algorithm that
starts searching before you even begin typing the search term. As soon as the find
panel is open, it's already building a list of possible search results, and narrows the list down as you go. In the time it takes you to hammer out the third o in "foo" the find panel has already found 50,000 that do not contain "fo" so they obviously can't contain "foo" either, and will not be searched.
Search should be efficient
Instead of a complicated find panel with buttons everywhere, I just present a
search box and a list of results, just like Spotlight. Use the up/down keys
within the text field (or ctrl-p/ctrl-n) to select the result you want.
Hitting return doesn't initiate a search, because it's already finished searching
by the time you get to that stage. Instead return closes the find panel and opens
the search result.
So, basically, if I need to navigate to the
function fetchRelative() declaration, I just hit
[cmd-shift-f], type "n fetchR" followed by
Unfortunately my app is really only alpha quality, and while I use it daily it's
missing some pretty important features, one of which being the find panel just
opens the file, it doesn't take you to the part in the file with the search result.
Until that is fixed (pull requests are welcome!)
You'll need to use the file navigation functions for that (hit
NSPasteBoard makes sure both find operations have the same search string).
I'm also intimately familiar with pretty much every mac text editor out there.
Sublime Text has a pretty good workflow for this, if you know the name of the
file the function is declared in, you can use the "Open Anything" function.
For example if you know
fetchRelative() is declared in
you could type
doc#fer to jump right to it. I will probably implement this
feature in Dux one day... unless someone sends a pull request first. ;)
It would be really nice to have a feature like Xcode or Visual Studio or Eclipse
where you can simply cmd-click a word to go to where it has been defined. I have
put a lot of thought into implementing this, but frankly I think it only works
stick with a simple find.
cmd-click on a word could bring up the find panel with that word typed
iPhone 5C thoughts
January 29, 2014
John Gruber came to this conclusion from Apple's financial results:
[The iPhone average selling price] means the 5S had a very good quarter, and that the 5C didn’t really change things much from Apple’s prior practice of selling year-old iPhones at the mid-tier price point.
It hasn't changed much now, but I wonder in another 6 months. Next time they refresh the product is line, is Apple going to continue selling the 5C but add a 6C model at the current price?
Everyone expected the 5C to be a budget iPhone, Donna Tam from Cnet published this quote from Tim Cook last October:
That was never our intent, honestly. Our entry iPhone is the iPhone 4S.
I think The 5C is the budget phone everyone expected, but not in it's launch year.
It won't compete with the Lumia 520 though, which appears to be doing great in emerging markets. Apple won't compromise on quality and it simply isn't possible to produce a good product at that price point — all the good Lumia models are in the same price range as the current 5C.
January 28, 2014
Jordan Golson, writing for MacRumors:
Intelligence agencies can grab data as it travels across the Internet,
looking specifically for data from smartphone apps including Google Maps --
searches within the app allow Governments to locate users to within a few
yards -- and even Angry Birds. Much of the information being sent seems to be
related to targeted advertising.
Worrying, but there was a glimmer of hope:
Apple CEO Tim Cook has been vocal in his disapproval of some of the NSA's
methods, meeting with the President to discuss NSA surveillance and more
recently saying the NSA "would have to cart us out in a box" to have access
to Apple's servers.
Perhaps some day Apple will force third party apps to reduce the data they
gather (they did it with newstand) or else lobby for stronger privacy laws.
January 23, 2014
Dan Goodin, writing for Ars Technica:
Typing "Brunch with Mom at Java 11am Sunday" is intended to schedule the event for the following Sunday morning at 11 and list the place as "Java." Participants can be added by listing their e-mail addresses, and in many cases, Google will respond by automatically adding an entry to the participants' calendar as well.
How could anyone possibly think this is a good idea?
January 23, 2014
Cyrus Farivar, writing for Ars Technica:
Verizon announced on Wednesday that it received over 321,000 total orders from
various American law enforcement agencies in 2013. It is the first major telecom
to publish such a report.
We need a way to communicate without these breaches of privacy. I see two
- Encrypting the message contents;
- Hiding the intended recipient of the message.
The first is easilly solved with S/MIME today (I use it myself) but the second
is the most commonly abused and much harder to solve.
January 22, 2014
Hopefully of many.