sadawi

SEEKING WORK (New York City + remote)

iOS developer (Objective-C and Swift) for the past 7 years, with full-stack and startup experience (mostly Ruby on Rails)

Recent projects:

  * built all of the NexTravel (YC 15) iOS app (https://itunes.apple.com/us/app/nextravel/id1098361345)
  * worked on the Wink home automation iOS/watchOS app (https://itunes.apple.com/us/app/wink-smart-home/id719287124)

Say hi! I'm [email protected]

To me, something like your syntax makes sense when there isn't a clear hierarchy among selectorPart1, selectorPart2, selectorPart3, etc. However, in every case where a method can be thought of as having a single primary action that is refined by arguments, I believe the action(argument1:value1, argument2:value2) syntax makes more sense.

I wouldn't want to see, for example:

  collectionView.(dequeueReusableCellWithReuseIdentifier:identifier, forIndexPath: indexPath)

because that obscures the primary purpose of the method, which is to dequeue a cell. To me, this is preferable:

  collectionView.dequeueReusableCell(reuseIdentifier: "ImageCell", îndexPath: indexPath)

The long first component of the Objective C selector ("dequeueReusableCellWithReuseIdentifier") is just an artifact of ObjC's lack of distinction between method names and parameter names, which forces the API creator to use words like "With" to accomplish what Swift can do natively.

What are some examples of methods you think make more sense with your syntax?

Looks like the pieces are reversible, so the two L's and two S's are actually L, J, S, and Z.

Of course, it's only a failing strategy if adopting that strategy causes everyone to adopt the same strategy, which is very unlikely for most people.

That's the way it should be. Otherwise, you'd be incentivized to leave (dishonestly) positive reviews.

One per year? Compared to cars, food poisoning, bathtubs, ladders, and almost anything else you can think of, that's close enough to zero to be a non-issue.

Ideally, I think the complete list of votes (with receipt confirmation numbers, but no names, obviously) would be available for inspection.

Sure, but there's a benefit to receipts: you can verify that your vote was counted correctly.

If the receipts are anonymous, they can't prove how you voted, only that you were able to obtain a receipt. So what if we increase the supply of receipts enough to destroy the value of an individual receipt? For example, voting machines could drop duplicate receipts in a bucket that voters have access to.

What you're buying isn't a vote, but a receipt. What if we could increase the supply of valid receipts enough to make them effectively worthless?

For example, voting machines could drop duplicate receipts into a bucket that voters are free to rummage around in.

I find that while a neighborhood filter gets the job done, its usability isn't great, for a number of reasons:

* You have to roughly know the boundaries of all the neighborhoods for the list of names to be useful

* A one-dimensional arrangement of names doesn't correspond well to the 2D relationships you probably care about.

* Many neighborhoods don't map well to regions I care about. I often find myself selecting Bernal Heights, Mission District, and Noe Valley to capture the idea of "the area around 24th and Valencia", for example.

Or just show the subtitles after a short delay. Or show a word-by-word translation in realtime. Or both.

Is lifetime earning to cost a useful metric, though? There are costs outside of college that won't scale with that ratio. Extreme example: a 1000:1 ratio isn't much good if your lifetime earning is $1000, and a 2:1 ratio could mean you come out ahead by a few million dollars.

Using UDIDs for authentication isn't a good idea for a serious app. Even if it were unspoofable, devices aren't users. Users have iPhones and iPod Touches and iPads; they upgrade; they sell devices to other users.