Generating hundreds posts with Octopress is very slow... On my computer, it takes ~40 seconds to do a full site generation, unacceptable for tweaking post or live preview. But usually we are just modifying one post, a full site generation sounds ridiculous, these two commands may help:
rake isolate[filename] # Move all other posts than the one currently being worked on to a temporary stash location (stash) so regenerating the site happens much more quickly.
rake integrate # Move all stashed posts back into the posts directory, ready for site generation.
After creating a new post (like this), we isolate it from all others by using rake isolate["speed-up"], generate only the new post takes about 2 seconds, 20x boost. When all done, run rake integrate to get stashed posts back.
I'm using Core Data and NSFetchedResultsController, and encountered mystery crashes related to them. Here's the solution.
The document from Apple mentions that if delegate is not nil, then NSFetchedResultsController will track changes to managed objects, by listening to notifications sent by managed object context and then call its delegate to modify corresponding UITableView. This implies if you don't set delegate to nil before it gets dealloced, then observation is still registered with NSFetchedResultsController and cause strange messages and crashes. We may see the following messages:
-[SomeStrangeReciver controllerWillChangeContent:]: unrecognized selector sent to instance 0x8251dc0, the receiver is random, I've seen __NSCFType, UITapGestureRecognizer, etc.
CoreData: error: Serious application error. Exception was caught during Core Data change processing. This is usually a bug within an observer of NSManagedObjectContextObjectsDidChangeNotification.
Assertion failure in -[UITableView _endCellAnimationsWithContext:] …… Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section after the update (1) must be equal to the number of rows contained in that section before the update (0), plus or minus the number of rows inserted or deleted from that section (0 inserted, 0 deleted).
(These error messages are from Google, and may be slightly different from actual messages)
Though we see different messages, the reason is the same: The observation has not been cancelled after NSFetchedResultsController gets dealloced.
Github surprised me in terms of the speed of support/development/review/deployment.
Yesterday when wandering around GitHub, I found a bug:
I haven't seen this bug in years of browsing GitHub, it has to be introduced by recent changes. I tweeted about it, and got confirmed by @zhengjiehan. Then I wrote a ticket to GitHub with screenshots and repo names attached. After that, I continued with my practice of Racket, since it usually take one business day or more to get a reply (it is Saturday, right?).
But I got a reply (and a laughter) in ~70 minutes, at 2:40 AM, UTC+8:
That's hilarious! Um, we just like being precise? Kidding. I'll write up an issue.
Thanks for letting us know!
OK, they replied quick, then I went on my work.
Less than 2 hours later, I got another mail (4:17 AM, UTC+8):
We've fixed this bug and the repo numbers should be looking much nicer now.
I then opened the 2 repos with problem, it got fixed!
I couldn't believe that, from a ticket to deployment, GitHub uses less than 3 hours! Ticket sent, received, support guy file an issue, dev get that issue, figure out the reason, fix it, pass peer review, get merged, and finally deployed in 3 hours!
I don't know why it's extremely fast. Perhaps their support service is run by developers, many developers are full stack, developers have the permission to deploy a modification with a single click…