Things to discuss IRL

[alloy]

I’ll be at the NYC office from April the 14th, we should definitely discuss:

• [x] The networking abstractions in Eigen: https://github.com/artsy/eigen/pull/277#issuecomment-83203488
• [ ] Get our certs and provisioning profiles figured out for once and for all, for all apps and beta/App Store versions: https://github.com/artsy/eigen/pull/291
• [x] Auction data being up-to-date is probably very important, as such polling and notifications can be unreliable sources. Discuss alternatives such as web-sockets.
• [ ] Discuss with @dblock about a possibility to have a shared JSON payload test suite that is verified against the API and can be used in other apps (Eigen) as test fixtures and for self-documenting purposes rather than reversing what the web front-ends do.
• [x] Discuss with e.g. @dblock about caching/preloading of at least fair content but probably also content such as /magazine and /shows:
  • All (?) API calls have a max-age of 0, so the `NSURLCache behaviour is to never consider the cached data.
  • We can force always use the cache (such as the ‘offline mode’ option that AFCache has), but then the question is how/when to update stale cached content.
  • Currently I enable ‘offline mode’ of AFCache when the device has no network connection at all.
  • But ideally we would also defer to the cache if the connection is ‘slow’, the question is ‘what constitutes slow’?
• [x] Talk with @orta about a custom Xcode test runner/reporter plugin and possible other features such as auto-run changed tests.
• [x] Discuss with @orta the idea of splitting eigen into a collection of smaller individual mini-app-like frameworks, ala Force / Ezel
• [x] Transitions of Language

[orta]

yesssssssssssssss - I have some great ideas here

[orta]

Talked with Soroush Khanlou a bit about networking, he gave us an example of what he uses, https://gist.github.com/khanlou/e0bc14836a4647a1ca8a

[alloy]

Possibly also meetup with @modocache about those testing ideas/issues?

[modocache]

Would love to talk more! I've been planning on writing in more detail about:

1. What are the core problems a test runner needs to address: Provide a customizable way to run a set (or subset) of tests, to announce which tests are available and at what locations, to notify observers of test results.
2. What features represent the "cutting edge" of unit testing: For example, runs examples marked as "pending", determines whether they've actually started passing, and issues a warning if so--"you've disabled this test, but it should be enabled because it already works". Another example: using deltas in test coverage to determine which tests should be run.
3. How Apple could implement these features: I enjoy thinking about these problems because it helps me understand the position that Apple is in. Yes, they should make their test runner infrastructure more modular, and allow developers to specify which tests exist, in which files, at which lines. How tests are defined, whether that be via an xUnit or xSpec framework, should be customizable--we shouldn't be forced to build on top of a testing framework like XCTest to run our tests. That much is fairly obvious--so why does the status quo exist? Maybe Apple is wary of how APIs they could provide would be abused? If so, what's the best way to prevent that?

We may have to agree to disagree about Xcode plugins. I have yet to be convinced that it's a good idea to build tools on top of private, undocumented APIs. And I'm not sure it's responsible to release those tools so that people new to testing on iOS become reliant upon them. Instead, I'd like to work with Xcode, not provide an alternative. But I'm open to contradicting opinions.

[orta]

I'd also like to discuss the idea of splitting eigen into a collection of smaller individual mini-app-like frameworks, ala Force / Ezel

[alloy]

@orta Sounds good :+1:

[ashfurrow]

yesyesyes

[orta]

and it can't hurt to bring up the elephant in the room too, Swift.

[ashfurrow]

omg Orta that GIF. So representative of our experience with Swift.

[alloy]

lol

So, I’m not sure how long we’d need to discuss Swift, once it’s really usable then, sure, why not? To be honest, it’s not really the bigger and more interesting elephant in the room, which imo is Android.

Swift doesn’t do anything for us in this regard. Therefore, I’d like to have a play with react-native to get a feel for it and see if that’s something that makes sense for a strategy towards Android. If react-native does turn out to be a good viable solution for that strategy, then I’d suggest we’d:

1. first move to react-native
2. start on Android work
3. write new or rewrite existing Eigen components in Swift

With that timeline, Swift would still be pretty far down the road, though.

[orta]

This is strongly in line with what I have been thinking about lately

[alloy]

Some points to consider from caching talk:

• Whitelist resources that are allowed to go stale. Never cache auctions!
• Determine network connection quality:
  • api/v1 system ping + 80ms
  • keep metrics, such as request time, with each cached ‘object’ so that we can then test against that later on and decide what is acceptable or otherwise determine that serving stale data is allowed.

[orta]

Rawish transcript, I'm bad at taking notes while talking

ED: React is like creating components which definte their own ways of getting 
ED: Our Caching can come locally. Probably similar on android.

SS : can we get metadata before?
OT: API v2 allows us to ask for things we want as a singular request
ED: Its kinda how it works now, API is built for website

AF: I like the network model appraoch, easy to test
AF: it takes all of the network activity out of the object
    it handles all information about the fair - it does the transference of 

OT: Let's kill promise based networking
    Replace with KVO + network models

AF: All deps will still need to  work
AF: but do we need to have the equivilent for android?

OT: 
  android shouldn't be a raw factor as the decision but a part
  we should continue for best for ios app we have
  We can steal people
  we become more valuable in artsy
  write more complicated apps
  we can make better things with 

OT: Test Laura + Sarah W could work on a settings VC as a test bed to get a sense of what

ED: I think it'd be sad to get to a state where we have to implement things twice
  : would be nicer to switch inbetween the teams ourselves
  : instead of you do x, and you do y.
  : I consider myself an engineer, not an ios one

Q for react-ers: Localisation
   How to transition
   How to take an existing View Controller and turn it into react native

OT: Polling for martsy?
ED: dB opened a ticket
OT: ask about amking a pollign contract that we can start and stop via js

OT: Testing, I don't believe Xcode will improve in WWDC
ED: we could build a Mac app, lists test, talks via XPC

AF: A way that works similar to Reveal via sockets, can try build something on specta/quick
ED: thats how OCTest works
OT: MVP is test file re-running on an XCTest thing

General gist for the longer term perspective:

• Look at react native
• Switch Promises to KVO + network models
• Talk with martsy about some functional contract for polling new auction data
• Start building our own test runner in a way similar to how Reveal works
• Caching HTTP stuff

[orta]

@modocache (BG) came to Artsy HQ to dig further into our test runner plans. As ever, my terrible write up

BG: 
  initially had no interest in a mac app
  wanna build x
  to figure out what I want is to build it

ED: 
  I have ideas around how this can work 
  the extension _is the test_

ED: the bundles isn't possible
  XPC + extensions is the same kind of architecture
  same idea, separate processes

BG: The issue of opening your sim?

ED: You dont ened to re-launch 
  : Sock Puppet app keeps running, spins extension

ED:
  Host app extension that spawns the extension
  no luaunch
  wouldnt work on a device

BG: I dont understad why it does any why it doesnt 
ED: It does not work
    Mac app is just a front
BG: Interested in writing the runner so people can launch an app and run an extension

BG: 
  Want to reverse engineer the underlying infrastructure
  that part is pretty tangential

ED: 
  Sim is unreliable, restart sim, restart xcode. The bridge is fragile.
  once the ism is done, it keeps running
  a relaunch is a lot of the wait

BG: 
  A better testing solution
  the hardest part is like "global state, inserting the right invocations"
  a better runner fixes that

ED: 
  Bacon is still my fav
  isnt the other problem with current infrastructure

ED: 
  a lot of simpler frameworks just raise an exception at the stio at one test failure in a single test
  think xctest has to keep 

BG: 
  `beforeAll/afterAll` run before suite 

ED: so how do you run one?
BG: 
  each block has a reporter object, that way you can get really flexible. Can message the reporter anything. Can do things like skip, pass through, and they can talk to each other
  alternatively a closure returns waht happens
  reporer can raise or fail

ED: runner starts, then framework can report it out
BD: its a function that takes objects as
    test runner should be as explicit as possible
    in objc that would be a macro
    make it a class, whatever

ED: test runner is a separate tool
    is it a separate runner, that runs

BD: my plan, is it goes to a main mainfunction 
ED: build it with specta/quick whatever
ED: lets say mac app
    it does  dry run
    results are relayed back
    how does that work?
    if the runner is a tool

ED: I did a macbacon that sent things via XPC
BG: assume I know nothing
ED: you make a runner, it exposes an XPC API that says
    give me a list of tests, the list of objects + closures
    it would expose an API for showing the API
    on every fail it send it back over XPC
    tests keep running and you can kill
    kill it the xpc process
    then it has a test runner has a focused test API
      "now only run this one" 
    as separate process
    this is what xcode is trying to do as xcode
    frontend needs to know state, other thing needs to say "now its time"
    but that reporting needs to be possible

BG: 
  rpsec runs pending examples and says if it crashes then it's ruby not your code
  junit does rules for whether a test takes 
  unwrapping options "assert this isnt nil"
  shouldnt out an if in your tests
  "clown town"

ED: 
  I want to be able to build really simple frameworks on top of there\
  needs to be a simple interface for xcode

BD: 
  I think theres things I dont get around the testing code

ED: 
  assume this thing is running, it is an app, a process. That only says" please give me code to run"
  sim is a mac on the app, has full test
  test gets build into an xpc bundle, which is also somewhere on the hard drive
  the test runner would generate the bundle on the harddrive
  and it would xpc and send something to the sim 
  runner would invoke the "artsy invocation thingy"
  it would signal
    create the bundle
    the sim app would take the bundle
    and then run the xpc stuff
    running the code 
    then send the signal back

  it would take more time than just running a closure
  bt its more efficient by far
  has a runner that just evokes the focused test
  can be optimised by keeping it running

  thats what I was trying to make sense of "is it time for us to build our own"
  not a far of building a pluigin

AF: you can send it a fake sim, to open, then do the right one the second time generally
So basically we xcrun Instruments with a named simulator, expecting it to fail because we don't inlcude an instrument to run, but the simulator is now launched and ready to be invoked by actual tools. See: https://github.com/artsy/eidolon/blob/8ca8ed0d19e68e5b62a524b594f0a8797bb41029/.travis.yml#L10

BD: 
  there is a world where the runner is the host could do anything

OT:  the runner could be a mac thing like rack
BD: the XPC thing can be everywhere
ED: Rack is a spec for how to nest applications
     we're doing something similar, because everything is so abstract
    you can build it as you see fit for the problem at hand,  so we can have different types of test runners depending on levels of difficulty
    I can see a thing that is this side is just reporting

Rack for test running.

[orta]

We went to Facebook yesterday to look at React native. My general notes

• React native is about having your own foundational objc and building on top of that
• Deadlines were met faster than expected
• Was nice to have fresh eyes come in to mobile
• They are experimenting with it in a bunch of apps
• Facebook office is nice
• They do transfer code between ios and android
• I should do a meetup there, bunch of space
• All about developer time improvements

[ashfurrow]

I should note that they specified that shared code between iOS <-> Android was currently not ReactNative, and revolved mostly around the low-level stack. It'll be interesting to check in with them in a few months to see how that's changed.

[orta]

Oh yeah, C++, eww

[ashfurrow]

Dropbox does the same.

[ashfurrow]

Now that we've discussed these topics, IRL, we should split this issue up into other, actionable issues.

[orta]

Done. Open to more :+1: .

[ashfurrow]

:clap: Well done.