Apple Developer Documentation Is Missing

Post by ChrisMarshallNY » Mon, Oct 28, 2019, 3:43 PM UTC

leshow wrote: post #142

ChrisMarshallNY wrote: post #126

Earlier quoted context omitted.

Ignoring dozens of repos (non-forked), and thousands of lines of testable, shipping code, is probably not helpful. I was a manager for a long time. I loved long résumés and relevant material. I was hiring expensive people to work on really important stuff, and there was no way that I wanted to rush the vetting. Also, I never gave a single test, and I think I got it right, every time.

> Also, I never gave a single test, and I think I got it right, every time. There's bound to be some confirmation bias there

Post by edw » Mon, Oct 28, 2019, 3:48 PM UTC

chriskrycho wrote: post #143

edw wrote: post #117

Nowhere in the comments thus far has anyone pointed out that SwiftUI — the framework in TFA's crosshairs — is in beta. I've written a relatively large amount of SwiftUI code and I get the impression that the design is still in flux. There are corner cases (as well as much more mainstream one) that haven't been fully thought through. Beta 5 of Xcode 11 brought non-trivial changes to the API and I expect those to conti…

Edit: this first paragraph is wrong, see child comment. Leaving for posterity. The second paragraph I stand by. SwiftUI is not in beta. It may be beta-quality, but they shipped it and encouraged devs to use it . Yes, it has undergone significant breaking changes since WWDC (and that's to be expected), but it's not described as beta anywhere in their docs about it. (See https://developer.apple.com/xcode/swiftui/ and h…

  iOS 13.0+ Beta
  macOS 10.15+ Beta
  tvOS 13.0+ Beta
  watchOS 6.0+ Beta
  Mac Catalyst 13.0+ Beta

Post by bdisnainc » Mon, Oct 28, 2019, 3:48 PM UTC

eugeniub wrote: post #121

ChrisMarshallNY wrote: post #88

Earlier quoted context omitted.

Think the ternary operator, but worse. In Swift, this is expressed by "??". It means "If the previous test returns nil, then execute what is after the ??". For example, if you have a concrete Int, but the source might be an optional, then you could do something like this: let a = b ?? 0 That means that if b is nil, then set a to 0. Otherwise, set it to whatever value b has. You can chain these, like so: let b: Int? =…

Strongly disagree with the "but worse" characteristic. As soon as you learn what "??" does, it's actually an improvement in readability in many cases. For example: nameLabel.text = user?.name ?? "Guest" This, as opposed to: if let name = user?.name { nameLabel.text = name } else { nameLabel.text = "Guest" }

    if (user)
      nameLabel.text = user.name;
    else
      nameLabel.text = "Guest";

    nameLabel.text = user.name if user else "Guest"

Post by ben_jones » Mon, Oct 28, 2019, 3:49 PM UTC

SkyPuncher wrote: post #127

ChrisMarshallNY wrote: post #70

Some time ago, I was contacted by Apple to apply for a job. My code is insanely well-documented. I like to think that a lot of the inspiration for my code docs comes from Apple's open codebases. Their code is exceptionally well-documented. In any case, as is usual with all employers, these days, they completely ignored the focused, relevant links that I sent them to elements of my extensive portfolio of repos, and, i…

> I'll make it clear that I'm NOT a fan of these. I am mediocre, at best, at them, as I don't come from a traditional CS background (I started as an EE). I come from a CS background and struggle with these too. The big problem I have is this performance stuff is often barely relevant to the position. You need to know the principle of a BST. Unless you're building a database working in a unique scenario, actually trav…

Post by ChrisMarshallNY » Mon, Oct 28, 2019, 3:51 PM UTC

mmahemoff wrote: post #122

ensiferum wrote: post #108

Earlier quoted context omitted.

Most interviewers don't give a crap about one's GitHub/Bitbucket/X portfolio. It might help one to get the interview in the first place but after that point it's useless. Why? Because any single interviewer has a set of well rehearsed questions they know like the back of their hands. They know the different possible solutions and understand their pros and cons. This makes the interviewing a routine that lessens the b…

Asking the same questions also makes it easier to compare between candidates and the questions can become optimised over time to ensure they are fair and valid performance predictors. Also, it's never obvious how much someone contributed to their portfolio. Just being able to explain it doesn't mean you were the sole contributor, or the contributor at all, and it doesn't give a great indication of how you work or how…