jackflintermann

I liked this article a lot - information-dense but approachable. It feels like you can understand the entire app using only the code snippets in the article, which speaks to the quality of the design. The only part that made me roll my eyes was the AI piece - I don't think there's any actual AI involved in the app, it seems like the author just used it to figure out what metrics to use, and then hardcoded them into the app? (That's probably how I'd do it, tbh - I just think the AI part distracts from the overall point and doesn't need to be in the post.)

Thank you!

I appreciate the thorough read!

For deprecations we're lucky in that the underlying systems don't change very much (the Input Message Accountability Data isn't going anywhere). But we'll run into collisions when we, for example, start issuing cards on Mastercard as well as Visa.

We have experimented with a couple of, um, abstractions, and may do so there. One rule we've stuck to, and likely would as well, is to keep the "substrate objects" un-abstracted but to introduce higher-level compositions for convenience. For example, there is no such thing as a "Card Payment" (https://increase.com/documentation/api#card-payments) - it's just a way to cluster related card authorization and settlement messages. But it's extremely useful for users and nontrivial to do the reconciliation, so we tried it. But we think it's essential that the underlying network messages (the "substrate objects") are also accessible in the API, along with all the underlying fields etc.

Unfortunately 100% of the public APIs I have worked on are in payments. I wish I had another lens!

I guess the phrase "no abstractions" is specifically valuable to us when designing our REST API resources - our whole stack is certainly an abstraction of sorts, but we don't want to add yet another abstraction in that specific layer.

Yes, exactly, the important thing to us is that our users don't need to build an additional mental model between us and the networks we sit atop. If you know the network, we want you to be able to intuit how our API works. There's a very real difference (arguably the fundamental value-add of our company) in the transport layer, though. The actual mechanics of integrating with, say, FedACH, are a bit long to get into here (we get into it a bit here if it's of interest: https://increase.com/documentation/fedach) but suffice to say it doesn't have a REST API.

Author here - this has been a useful mindset for us internally but I'm curious if it resonates externally. I'd love your feedback!

I took a crack at recreating this in javascript once the necessary APIs made their way to mobile safari - https://highphone.app if interested! (iPhones only, sorry)

(Increase employee)

We took the approach of starting with an intentionally bad name (in our case, bnk.dev) and using it until a good domain became available to purchase for a reasonable price.

Related: http://www.paulgraham.com/name.html

Haha, sorry! I snagged it for a friend. Bought it immediately upon sight - wasn't gonna let it get away after someone got sailbo.at from under me.

Wow, this is really good! I'm surprised at how many shortwords are still available given a little creativity.

Neat idea overall! Some small feedback: - You should check and see if the device has rotation lock enabled (or use a rotation API that isn't affected by it); I keep it on by default and the game wouldn't work for me until I thought to turn it off. - It's pretty easy to accidentally tap an ad and thus destroy your game session.

My top 3 are probably:

- the iOS dev weekly newsletter (iosdevweek.ly)

- NSHipster (nshipster.com)

- objc.io (objc.io)

Hmm, github.com is throwing a 500 error at the moment. I wonder if this is somehow related?

Great question. For classes with sufficiently rich customization options (UISlider, UIStepper, UIBarButtonItem, etc) I don't think it's necessary to provide a full-on subclass, as ultimately I'm not really changing what the class does. I'm really just providing a mixin for a particular set of UI customizations (setting colors, etc), which categories are perfect for.

Some classes (UIAlertView and UISwitch, most particularly) aren't very flexible in terms of appearance customization, so I had to reimplement them to achieve desired effects. Using them is more difficult: to use an FUISwitch (my UISwitch clone) you have to replace any UISwitches in your app with FUISwitches (also, if you were using categories/subclasses of UISwitch to do some custom stuff, they would break).

Moving logic to a base class isn't really possible, as most of those classes already inherit from UIControl (and I'm not crazy/motivated enough to reimplement them all from scratch - UIKit is awesome, and I want to lean on it as much as possible).

The single header totally makes sense, I'll be sure to add that.

TL;DR: UIKit is great, I don't want to reinvent the wheel, categories are really easy to integrate into existing projects.

Yeah, FUIButtons have a shadowHeight property which can simply be set to 0.

That's a really good observation re: accessibility, and something that had totally slipped my mind. I'll add accessibility support for FUISwitch and FUIAlertView in the next release (everything else, being a subclass/category of existing UIKit stuff, should have it already).

I'm using CoreGraphics for a lot of stuff here, just not actually in the controls' drawRect methods. Rather, I use CoreGraphics to produce UIImages of various sizes/shapes/colors and then use the appearance methods provided by each UIControl (e.g. setBackgroundImage) to style existing UIKit controls with said image. So there aren't any external images included in the project. I prefer this approach, as it minimally interferes with each control's existing/desired behavior (not to feed the trolls, but one of the weaknesses in the "Apple wouldn't approve of this" argument presented elsewhere in the comments is that I'm almost entirely just using existing classes/appearance customization APIs provided by UIKit).

Thanks! It feels good to get this out there - we want (and plan) to open-source more stuff but have been so busy that we haven't had the time. Deliberately writing this to be open-sourced also made me a lot more considerate when developing it and improved the code quality as a result.

Hey Mason, appreciate the feedback. Actually, all of those bugs are fixed in the 1.1 release which came out on Friday night. So just update and you'll be all set!

Hey everybody, creator here. Let me know if you have any questions/comments/feature requests - I'm going to keep working on this.

It's also the name of a great short story by Cory Doctorow (link below). Bit of a ripoff by MS on the title. http://blogoscoped.com/archive/2007-09-17-n72.html

This looks like it's getting HN'ed, google cache is here: http://webcache.googleusercontent.com/search?q=cache:srirang...

CS129 (Computational Photography) at Brown actually has students reconstruct these same photos as its first assignment. It's not too hard, and a good introduction to image alignment. Check out the assignment at http://www.cs.brown.edu/courses/cs129/asgn/proj1/

Here's a link to the non-mobile version: http://www.wired.com/threatlevel/2012/05/ff_counterfeiter/al...