449 karma · joined September 7, 2009
Not sure that's my favorite (and I've gotten a lot less picky about programming fonts over the years) but it seems an odd omission.
Any particular reason why you're avoiding the C99 _Bool?
> Facebook is not and has never been part of any program to give the US or any other government direct access to our servers.
We have however set up a tap that mirrors all traffic to Facebook to NSA servers, and we've given them the certificate to decrypt that traffic.
> We have never received a blanket request or court order from any government agency asking for information or metadata in bulk, like the one Verizon reportedly received.
Instead, we were requested to provide our SSL certificate and to install some hardware in our data center. We never handed over any data ourselves.
> And if we did, we would fight it aggressively.
Too much work to provide all that data. Best to just give them a mirrored PHY stream.
> We hadn't even heard of PRISM before yesterday.
We didn't know _what_ the program was called; they never told us, specifically for plausible deniability reasons.
> When governments ask Facebook for data, we review each request carefully to make sure they always follow the correct processes and all applicable laws, and then only provide the information if is required by law.
Technically, they didn't ask for user data, they asked for a hardware interconnect and a private key.
> We will continue fighting aggressively to keep your information safe and secure.
Our lawyers made us say this. C'mon, we're Facebook, what do you expect?
> We strongly encourage all governments to be much more transparent about all programs aimed at keeping the public safe. It's the only way to protect everyone's civil liberties and create the safe and free society we all want over the long term.
Good God, what have we done?! We're under an NSL, can't you tell that, people?!
Explain the interior pointer problem, when it applies, and what you can do about it.
Describe what happens in objc_msgSend, and give two reasons why it's implemented in assembly rather than C.
How would you implement NSMutableSet?
Explain the proper uses of (__bridge), (__bridge_retained) and (__bridge_transfer) casts.
Explain all the important differences between direct ivar access and access through a property, under MRC and under ARC.
When should you use +/-conformsToProtocol: instead of +/-respondsToSelector:?
How would you implement toll-free bridging?
The lack of women on panels is a symptom. You don't fix a problem by treating the symptoms, even if there's some circular feedback. In this particular case I think there's very little feedback. How many girls are discouraged from programming because they didn't see women on panels? Or for that matter, how many boys are encouraged to do programming because they didn't see women on panels?
Panels just don't matter that much. Fix the problem at a lower level - get teachers to encourage girls to go into STEM or programming, and get them to encourage the kids' parents to encourage them. Squash sexism in the classroom - "I don't want to be lab partners with _her_, she's a girl" should be right out, but so should "I don't want to be lab partners with _him_."
It's a matter of mindset, and one that can only be fixed in the young. Tech has, latent sexism (and possibly racism) aside, a highly meritocratic culture. Pledges like this will cause men and women alike to question whether a female speaker is there for her opinions or to fill a quota, whereas before, few as they might be, if women were there, there'd be no question that it for was their opinions and expertise. This doesn't remove the latent sexism, it hurts the meritocracy.
This is a known ARC bug. Implement -dealloc and nil out the managed object ivar (or property) and MOC ivar (or property), in that order.
> The biggest problem I have with Core Data is that there is just not enough "best practices"-type documentation out there.
I wholeheartedly agree.
cmnd-tab and cmnd-` work during drag and drop in all but the most poorly written applications. And most of those poorly written apps are broken in Lion anyway.
> With the Path Bar in Finder you have a similar mechanism but you have to drag-and-drop, which is, well, a pain in the ass.
Oh, I agree, but that's a problem with NSOpenPanel, not the Finder. Subtle distinction, but it's there.
> The closest I've gotten is a right-click->Get Info and then you can copy the "where" plain-text path.
Copy (cmnd-c) the folder or file puts the whole path on the clipboard (along with a file: URL and file promise - which gets used is determined by where the paste takes place).
You can: View>Show Path Bar. You can click/drag any folder in the path to get a file: URL or file path depending on your drag destination. Alternatively, your current selection can be copied/pasted into Terminal.
> Directory and file sizes without having to use "Get Info".
Use list view, pick Size as a column (should be a default, you may need to rearrange to get it visible next to the names). View>Show View Options; check "Calculate all sizes" for directories.
> Preview pane.
Column view has it directly. Hit space in List view for QuickLook, move the QL panel off to the side, and continue browsing. In Icon view: View>Show View Options; check "Show icon previews"; resize them large enough (≥48x48, IIRC) and movies can even be played inline.
Though this may sound a bit snarky, I mean it as a serious inquiry: have you actually used the Finder for more than 5 minutes since 10.4?
No, DTerm is not built in, but that's okay - no one's stopping you from installing it, or writing a better one†. The Finder doesn't have Dropbox built in either, and that's okay too.
†for instance, one that does the opposite: keeps a Finder window for each tab and window in Terminal on the current working directory.
A bit of history:
The classic Mac OS Finder never had a tree view. Heck, for a couple System versions, the file system (MFS) didn't support more than one level of folder hierarchy, so it would have been completely pointless. With HFS in System 4 (IIRC), that changed. Still no tree view though, and I don't think it was until System 6 that there was a list view, and not til System 7 were there disclosure triangles so you could drill down. (fun fact - though on OS X, you can adjust a slider to change icon sizes, back in OS ≤9, there was also "Small Icon View", which used 16x16 icons instead of the traditional 32x32, and put the labels to the side, rather than underneath) Despite a few other miscellaneous additions to the Finder over the years (tab view, At Ease (not really the Finder, but it shipped with certain Mac lines)), for System 7 through OS 9, most folks' file systems weren't that deep or complex. Having a tree view would have been mostly unnecessary and very Windows-like, which was something to avoid back then. There was even some outcry in OS 8 when the system got menus where you didn't have to hold down the mouse button to keep them open.
Come at it from the other side, NeXTStep Workspace's primary view was column view. So naturally that was left in the OS X Finder along with icon and list views from classic Mac OS. If tree view has ever been discussed at Apple in the past 15 years (and I wouldn't be surprised if it hasn't), it was almost certainly rejected as a throwback to the old Windows Explorer ca. 1995. Anecdote: in 2008-ish, at WWDC, there was a feedback forum, and while I can't remember what prompted the question, I asked if there were going to be resize handles on all the corners. I actually got boos from the audience and a look of horror from most of the panel, and a straight up "No. We're not doing that, probably ever. No way." as an answer. (Years later, I couldn't help but smirk when Lion had resize handles on all corners and edges.) The point is, if something potentially useful has too many associations with Windows, it was (and still is, to some extent) taboo.
id foo = @{ @2, @5 };
an NSArray containing two NSNumbers, or an NSValue containing a struct with two pointers (which happen to be NSNumber *s)?
I'd guess there were other edge cases they didn't want to deal with, so they didn't do literal NSValues for this release.
Or it could be that it's because []-style arrays are popular these days.
Or some of both; in picking which {} to change to @[], they reasoned that lots of people have experience with []-style arrays.
The Mission looks seedier the further north you go, but the crime rate is actually higher in the south. Don't live on Capp St. in the Mission; it's known for stabbings and prostitution. In the 'loin, once you get above Geary, things get nicer rapidly (as it's between the Tenderloin and Nob Hill, it gets the appellation "Tendernob"), but I wouldn't live south of Sutter St.
Hunters' Point in the far southeast is about the worst place in the city to be or be near, but I'm told Silver Terrace (between 101 and 280) isn't too bad.
30th St. is not the southern end of the city. There are (from West to East):
Lake Merced (far from everything) Park Merced (just south of the central Sunset, not TOO bad a walk from the L streetcar) Ocean View, Stonestown, and Ingleside (I don't know anything about them other than that the K and M streetcars run there) West of Twin Peaks/West Portal (nice area at the end of the Eureka Tunnel, kinda like Noe Valley, but with decent public transit) Balboa Park (has BART and freeway access, but not a great neighborhood) Excelsior/Outer Mission (like the Mission, but less convenient, worse food, and whiter) Mission Terrace and Cayuga Terrace (like a suburban subdivision in the middle of the south of the city, but more convenient to food. The J runs right next to it) Glen Park (north of Mission Terrace, it has BART, 280, and is slightly less seedy than Balboa Park; technically it has the J too, but that's really kind of a stretch since you have to walk over 280 to get there. The northern parts of Glen Park run into the south end of Noe Valley) Silver Terrace (see above) Hunters' Point (see above)
NSIndexSet *indicies = [allRecords indexesOfObjectsPassingTest:^ (id obj, NSUInteger idx, BOOL *stop) { return [obj someField] == someFieldFilterValue; }];
filteredArray = [allRecords objectsAtIndexes:indicies];
EDIT: oh, someFieldFilterValue was an integer, wasn't it. Fixed.
Thanks.
Additionally, commenting every bit of the code, especially as you go along, leaves one prone to forgetting the most important reason to comment: explaining the rationale for what you're doing. Explaining the design decisions in comments (and especially why you didn't do the alternative) is invaluable, and much more accessible to a maintainer (such as oneself a few months later) than an external design document.
Looks like the scientific computing poster session has been dropped this year too.
Why? There's a few things that you can't do with a Terminal, such as seeing and easily editing all the info from Get Info at once, or most things involving the use of a contextual menu - especially seeing what programs are in the Open With list (there may be a launch services related command, but you still can't pick one without typing another command (open -a Application file). Multi-file drag and drop is easier than multi-file cp, especially if you don't need a particularly named group of files that you can use a wildcard with - it's easier to shift-click or command-click than to type each one out individually, even if you can use tab completion.
* aliasing cd to end with an open . won't do, because that brings Finder to the front (which you can work around in bash), along with all the other open Finder windows (which you can't), and worse, it opens a new window every time instead of reusing the same one (another can't work around). The last two are because you can't, as far as I know, get a handle on a particular Finder window. I wonder if an AppleScript can get the job done. Hmm...