artsy / mobile Goto Github PK
View Code? Open in Web Editor NEWMobile Team TODO
Home Page: http://www.objc.io/issues/22-scale/artsy/
Mobile Team TODO
Home Page: http://www.objc.io/issues/22-scale/artsy/
Giving myself a due date - will have something up by Friday
We currently have 2 separate versions of View In Room, with different features.
Now all our apps are iOS8+ we can use SceneKit to generate a view in room, room.
I made a quick prototype of this as a mac app in swift
But going from that, to
is a tricky job. It's a bit easier building it initially as a separate mac app because it's faster to iterate and we have more input devices to work with.
Our VIR assets have always been done in 3d and then we've worked with the rendered outputs, so it might be possible to get some of the original assets. I'll ask @robertlenne.
eigen-private
that we can use when something shouldn't be discussed publicly for whatever reason.If we wanted to move a View Controller from Eigen, or to offer limited versions in one app but not another we would need a way to separate out the dependency graph.
Assigned to @ashfurrow for investigation
Judging by our conversations with Facebook, it doesn't sound like one of the big selling features of ReactNative is to share code between Android and iOS, as was our hope. Worth continuing to investigate, but in the mean time, I have some thoughts about breaking our apps into smaller pieces so at the very least, we can share code between eigen/energy/eidolon.
So this is what I'm thinking:
We have different pods for different view controllers. They are well tested. They abstract things away. In apps, like eigen, energy, and eidolon, you subclass them and get a bunch of stuff for free. They'd live in their own pods – open source, but not on Trunk.
OK, so that we can all agree on. What about the architecture of these (abstract-ish) view controllers?
self.view
if possible, to avoid loading the view hierarchy unintentionally.- (void)whatever:(void (^)(NSArray *whatevs))callback
[self.signal subscribeNext:^(id x) {
if (callback) {
callback(x);
}
}];
}
Or whatever we need (error handling, etc). It would be awesome to find a way to make writing the "subscribe to a signal and return whatever is next" sorts of methods easy/fast. Maybe a C macro? Or auto-generated code? Dunno.
Next steps would be pulling small, similar view controllers out of both eigen and energy to see how much overlap there is. Do this a few times and we'll have an idea of how much effort this would be, the potential benefits of doing this, and a rough timeline of steps.
@artsy/mobile
After talking with @orta and @katarinabatina over the past months, it’s becoming more and more clear to me that the current approach of trying to essentially replicate the Artsy platform in a native application doesn’t scale very well.
We’re often just playing catch-up with changes on the web apps and because we’re dealing with native code, these changes often take more time to implement than on the web. This means that there’s little time to actually work on awesome features for our users that would only be possible in a native app.
Besides that is also the issue that the web app can be updated and deployed immediately, whereas the native app has to deal with the App Store review time, making this an even more painful experience.
My suggestion is the following:
Pros:
Cons:
We should do beers / lunch / something
We should have a minimum vacation policy in 2015. See here for relative details.
This can probably work by us encouraging each other to take time off, until we know they've hit the minimum. Which should be the same as a cool enlightened country like Denmark. I wanna go live there some time.
What considerations are made, test coverage, community support, pretty README, code quality etc.
Sometime. Soonish. /cc @sarahscott
I'm thinking this would be a good show, if you're all into that?
What is it, in our opinion?
Rack for Testing, using XPC to communicate between each part of the system.
With the MVP goal to be able to run a test harness inside a hosted app and to be able to pass tests in via XPC to be ran without restarting the sim.
Ideally can split into three parts [ UI ] <---> [ Test Compiler ] <---> [Test Runner ]
Wherein the same UI could exist for many types of languages and test compilers, runners don't have to be some async running process. Could just be the same thing ran instantly but provides a separation against crashes etc.
Initially letting @modocache take a stab at this, but we can take a shot anytime @alloy feels he has some space. Assigning to him, as it is would be largely his work I expect.
Hello Artsy Mobile team!
There are a large number of workflows for managing and releasing an app:
over @paperlesspost, we use a "feature branching" model:
I've spoken with a dev from Pinterest who stated a similar workflow, and as of ~2 years ago, Facebook iOS followed a similar model (not sure if they still are).
I've more recently been enlightened to learn about "Git Flow", which we are beginning to trial-run right now. (http://nvie.com/posts/a-successful-git-branching-model/)
It encourages devs to ship smaller branches to the "integration" (or "development") branch after receiving CR, and having nightly builds of that branch be QA'd. This all ties into CI automation of tests, as well as developing new feature behind "feature toggles". It also changes how QA functions, having them test nightly builds, rather than "feature branch" builds
There are some other topics related such as:
I know you have written in the past about Arty's 4(?) week release cycle (not having luck finding it right now if you could cross post!)
I've also read up on an earlier post: https://artsy.github.io/blog/2012/01/29/how-art-dot-sy-uses-github-to-build-art-dot-sy/
and could see this as a part-2 elaborating on it.
What is Arty's workflow for successfully developing and shipping apps?
Thanks as always for working in the open! Incredibly helpful resource for learning
Deadline is this Friday.
URL for gdocs: https://docs.google.com/document/d/1XCeRU3f4HaBHb7eQcc4MSDVZc-5k5CtwyXpAuQepGNs/edit
We've thrown in most of the structure, and filled out a lot of the paragraphs. Most of the work revolves around hooking things together and polish.
As per #52
I though this was a nice idea, https://twitter.com/andy_matuschak/status/535860039391539201
We should do something like this. Any thoughts? It has to have tea. You're not allowed green tea. Or Coffee, cause that's not tea. Tea.
We want to put some time in before making any larger technology decisions.
Discussed today and we think it makes sense for @1aurabrown and @sarahweir to devote week 6 time this sprint to tackling an aspect of eigen in React Native. May 25th - May 29th. @1aurabrown should do some research, and run through some tutorials beforehand too.
@alloy can improve:
api/v1
system ping + 80msI know that we went into it at "Artsy Mobile's Culture" but that doesn't go into bundler, fastlane, pods etc etc.
What have we programmed ourselves away from, ideas:
Use ARModernEmailArtworkViewController as an example of migrating towards more maintainable code via class composition via:
I’ll be at the NYC office from April the 14th, we should definitely discuss:
/magazine
and /shows
:
max-age
of 0, so the `NSURLCache behaviour is to never consider the cached data.I noticed that on the eidolon project the pull requests go in the form of:
@[person name]=> [Actual title]
Is this a form of: "hey, I made this PR, please review it"?
@orta I was thinking in a blog post, you could talk about how instead of polishing it for open source in secret, before opening it, you only removed keys and would instead work on making it open source-friendly _
we have to move to do github style PRs
orta [12:18] of same branch repos, I think to get working CI
Once we, you know, do them.
Hi all,
Given that @alloy works remotely, @1aurabrown is in and out due to jury duty, and both @ashfurrow and @orta are devoted speakers on behalf of the team, it would be great if we could start to schedule things more "visually" so me and the rest of the team have more of an idea when people are online and available versus working on a talk, out of town for a talk, workin' on the house boat, etc. Scheduling things in advance will also help us to understand how much we can get done on a particular sprint.
Using the team OOO calendar should also be something we feel free to use but Orta suggested that a specific mobile team calendar may be helpful. Thoughts?
dooooooooo ittttttttttt
This is a happiness enhancement for me.
Doesn't have to be OSS, but I think this lowers the barrier to making little hack projects.
Something that can build off Dave's - dbgrandi/dbgrandi.github.io#8
I've been giving a bunch of talks to hack schools with a lot of low-level pragmatic advice around both contributing to OSS and getting your first job and doing well in it. Can build off that.
Expectations vs reality, sore spots, easy wins, ways to avoid hard times migrating to Swift 2.1, reasons why to/to not migrate now, lessons learnt.
We should do beers, or lunch, or something.
The Artsy mobile team is pretty good with remote workers, but we could definitely be better. There are some recent improvements to things in the office space – which are awesome – but need to be matched with corresponding changes with team culture.
Talking with the Squarespace team today, they had some really cool ideas. Things like:
I asked about the biggest problem they faced, and unsurprisingly it was information dissemination. How can we make it easier to relay the sort of in-person conversations that happen in the elevator to remote workers? How can we simulate those types of interactions with remote peeps? Not only are they missing out on that stuff, but we're missing out on more meaningful connections with them.
So: anyone have ideas? Suggestions?
So, you'd write a DSL which is given a few ivars e.g: lines_of_code
, pr_url
, number_of_commits
, files_modified
, files_added
, files_removed
Culturefile:
if (lines_of_code > 20) && (files_modified.includes? "CHANGELING.yml" == false) {
fail "needs to have a changelog note for large changes"
}
if (files_added.length > 2) && (files_modified.includes? "ARAppDelegate+Analytics" == false) {
warn "You may want analytics"
}
/x/:id
routesJLRoutes does nearly everything here, but that it returns a BOOL rather than returning a VC. Could look into making a fork that does this, then see what Joel thinks.
It's really cool and we should talk about it.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.