Artsy Engineering

Why does my team's Podfile.lock Podspec checksums change?

Tue, 03 May 2016 12:09:00 +0000

We use CocoaPods, and we don't check in our Pods directory for one of our fastest moving apps, Eigen. This sometimes can cause an interesting data churn inside the Podfile.lock when developers have different sha checksums for their Pods. This is weird, what gives?

What are the Lockfiles?

First off, to ensure we're talking about the same thing, this is our Podfile.lock. The lockfile is used on pod install to ensure all the members of your team have the exact same version of the libraries as each other. Otherwise, with a Podfile like:

platform :ios, '9.3'
pod 'AFNetworking/Serialization', '~> 3.0'
target 'MyApp'

A developer running pod install would get the latest 3.x version, which could be 3.1 originally, but then 6 months later they could get 3.4 - without a lockfile there is no way to keep track of the specific build. This is why it should always be in your code repo. In the case above my lockfile looks like this:

PODS:
  - AFNetworking/Serialization (3.1.0)

DEPENDENCIES:
  - AFNetworking/Serialization (~> 3.0)

SPEC CHECKSUMS:
  AFNetworking: 5e0e199f73d8626b11e79750991f5d173d1f8b67

PODFILE CHECKSUM: 876ceaa409f4ade2b3d58d310dbe026393824bcc

COCOAPODS: 1.0.0.beta.8

What do the Spec Checksums do?

With the CocoaPods Master Specs repo, we do our best to try and ensure a write-once repository of Podspecs for the public. However, there are many times when you cannot guarantee that every you have the same version of a Podspec as everyone else in your team.

So, CocoaPods makes a checksum of the JSON representation of your Podspec and keeps that in the lockfile. You can easily replicate the work to generate a checksum with:

~/D/MyApp ⏛  pod ipc spec ~/.cocoapods/repos/master/Specs/AFNetworking/3.1.0/AFNetworking.podspec.json  | openssl sha1
5e0e199f73d8626b11e79750991f5d173d1f8b67

So why am I seeing churn?

A normal git development flow when working with libraries is to:

Fork a library, change your Podfile to reflect that change
Make some changes
Commit them back to the main repo
Update the Podspec, then make changes bringing your Podfile back to a real (tagged) release

CocoaPods is smart about updating your libraries behind the scenes, but it's not perfect. In order to avoid re-creating your entire Pods folder every time it will check whether your libraries are at the expected version and skip re-creating the whole process.

In the example above, we used the CocoaPods' Specs repo version of the Podspec. In forked repos, e,g,

pod 'AFNetworking/Serialization', :git => "https://github.com/orta/AFNetworking.git", :commit => "6f31b5c7bcbd59d4dac7e92e215d3c2c22f3400e"

The Podspec is saved into the Pods directory in JSON format at Pods/Local\ Podspecs/AFNetworking.podspec.json, this is to ensure there's always access within the CocoaPods sandbox for the Podspecs, and speed probably. This is the podspec used for generating the checksum.

So how can this get out of sync?

During the development cycle, when working with a library you would have used pod update [library] to update just that library you were working on. This could happen multiple times as you build your changes.
You continued working against your fork till it was ready for review. At this point you have a working version, you submit a PR for code review on the library.
There are changes that affect the podspec that come up in review, you don't do a pod update [library] but send the code back to review ( maybe you changed some metadata for example, which doesn't warrant another update to pass CI. )
Once all code is reviewed, everything is merged back into master.
You pod install - which continues to use the older version of the Podspec inside the Pods dir, e.g. Pods/Local\ Podspecs/AFNetworking.podspec.json.
You now have the older AFNetworking.podspec.json inside your local Pods folder, when the next person runs pod install with your changes merged, they get a different SHA, as they've got the version with the metadata changes.

Simple Fix

The best option is to run pod update [library] on the computer which is causing churn, this will tell CocoaPods specifically to request a new version of the library. If that fails to give the same checksum as the rest of your team, there's the good old fasioned rm -rf Pods && pod install.

Using Paw with Per-Developer Settings

Thu, 14 Apr 2016 12:09:00 +0000

I am a big fan of developer tooling, as spending time upfront on improving your process can pay a lot of dividends over time. I want to talk about one in particular: Paw. Paw is a native HTTP client with a bunch of features. I want to cover one that means that we can now introduce [AppName].paw files in our mobile projects, making it easy for us to discuss networking requests.

OK, what is Paw?

Paw is a tool that stores collections of API endpoints, along with all the metadata required to call them. We first started using Paw during the creation of Eidolon as a way to keep track of the auction-related API calls we would need to stub for Moya, an iOS networking library that required stubbed data. It made it easy for us to keep track of how all the different API routes work together, and to verify that we were doing things right.

We used environment variables to keep track of things we wanted to change, but in using them this way we couldn't publicise our Paw files, the real versions contained secrets that should stay secret.

The environment tooling made it easy to change the routes, users and settings easily, but were also the thing keeping us from being able to share the files in source. Because of this, we stopped using Paw to keep track of our routes as we had to ad-hoc share the file over chat.

A Second Shot

This week, roughly a year and a half later, I started work on a large project that I knew would involve using new networking APIs. So I took the time to look for ways to interpret what I was going to be working with. After exploring some alternatives, I came back to Paw, and discovered they had a new feature: Keychain integration. This stopped my search.

In our iOS projects, as they are all open source, we use CocoaPods-Keys to ensure that our development configuration secrets are kept safe and outside of the project's source code. It stores the per-project keys inside a developer's Keychain. This means they can be accessed from inside the iOS app, but also from the developer's computer via a determinate location in the Keychain app.

~/d/i/a/energy (master) ⏛  bundle exec pod keys
Keys for Folio
 ├  ArtsyAPIClientSecret - [***********]
 ├  ArtsyAPIClientKey - [***********]
 ├  HockeyAppBetaID - [***********]
 ├  HockeyAppLiveID - [***********]
 ├  IntercomAppID - [***********]
 ├  IntercomAPIKey - [***********]
 ├  SegmentProduction - [***********]
 ├  SegmentBeta - [***********]
 └  SegmentDev - [***********]

This means that we can use CocoaPods-Keys with Paw in order to use the same ArtsyAPIClientSecret and ArtsyAPIClientKey environment config variables. Great. This is almost enough to make the first API call to to get an access token.

I re-used this idea to allow developers to have unique username and passwords. I created two more entires in Keychain, username and password. This is something that every developer using our Paw file has to do, otherwise Paw won't know who to log you in as.

With these all hooked up, I could set up Paw to use all of our Keychain entities:

Tada! Now I can run my route, and I've got an access token to use with our API.

Route Resolving

Automating the route to get an access token is the first step because Paw allows you to use the output of one route inside any new route. I'll show you, then talk it through.

I made it so that my new request ( for the route api/v1/me) passes in an header of X-Access-Token, with the value being the access_token from the route we just made called Auth. This means that when the token expires, it will automatically re-generate a new one and we're never storing the token explicitly inside the Paw file. Our secrets stay secret, and per-developer - I don't want to know other people's passwords.

Once those two routes were set up, it was a matter of looking up what routes I would need and added them to the paw file for the project. I used the group system to make it easy to show / hide sections, and experimented with using environments to differentiate between staging and production servers. Not quite figured that yet.

Wrap up

It's easier to talk about your API when any other developer can open this one file and shoot off requests at the same time as you. One of my favourite nice-touches is to be able to easily convert any request into a cURL command.

I am using this event as a reminder to myself that tools evolve, and maybe your first impression on a developer tool may require re-interpreting in light of software evolution.

Using Xcode's Schemes to run a subset of your tests

Wed, 06 Apr 2016 12:09:00 +0000

Eigen has hit the point where testing is a chore. This is a positive sign, the app has grown in terms of size, complexity, and number of developers considerably over the last 3 years. The test suite makes us feel comfortable making changes.

On my fastest computer, we're just under a minute - Executed 1105 tests, with 1 failure (0 unexpected) in 43.221 (48.201) seconds for the whole suite. I think I could probably live with 20 seconds max. So I studied how AppCode handles running tests, and this will be an illustrated guide as to how you can easily run the subset of tests in Xcode based on their techniques.

I have ideas on how to improve time for testing in general, based on Code Injection, but they aren't fully fleshed out and I expect it to be time-intensive to pull off. Time I haven't made yet.

What are Schemes?

An Xcode scheme defines a collection of targets to build, a configuration to use when building, and a collection of tests to execute.

You can have as many schemes as you want, but only one can be active at a time. You can specify whether a scheme should be stored in a project—in which case it’s available in every workspace that includes that project, or in the workspace—in which case it’s available only in that workspace. When you select an active scheme, you also select a run destination (that is, the architecture of the hardware for which the products are built).

To quote Apple.

Hatching a Scheme

The Eigen Test Suite is around 50 test classes, these look a bit like this:

Before you start, you want to be able to say, "I want to only run tests for the Fairs section of Eigen", as that is where I will be working for the next few days. To get started, I need to create a new Scheme. You will have seen the schemes before when you click on the Target side of this Targer/Sim button in the top left of Xcode.

This is what it looks like on mine, we want to create a new scheme. This brings up a modal window where you need to choose your App's target (this is so you can continue running by pressing cmd + r.)

I've called mine "Artsy just for Fairs", as I'm the only person who would see it, I can name it whatever I want. Clicking "OK" selects it, and hides the modal. You now need to go back to the target selector, and go to "Edit Schemes ..." to continue though.

Making Amends

OK, click on "Test" in the sidebar, and now you're in the Schemes Test editor. This is where you do the work.

You need to hit the "+" in order to add your Test Target to the Scheme

Select and "Add" you Targets. This adds the target, you then need to click the disclosure arrow in order to show all the Test Classes.

OK, here's some magic. Hold alt and click on the blue tickbox to the right of your test target to turn it off. Then click again, without alt. It should then deselect all of the classes. This is standard in all Mac apps, so go wild there.

This means you can go find the classes you do want to run, in my case that is the Test Classes relating to Fairs.

Now when I press cmd + u it will only run those test classes.

Wrapping Up

Which means I can now get back to work at a reasonable pace. Executed 15 tests, with 0 failures (0 unexpected) in 0.277 (0.312) seconds. I can then run the full suite whenever I go and make a cup of tea.

Note: If you want to avoid using the mouse to change scheme, the key commands to change between visible schemes is cmd + ctrl + [ and cmd + ctrl + ].

Artsy's Engineering Organization Stack, 2016

Mon, 28 Mar 2016 00:00:00 +0000

The Artsy Engineering Organization "Stack" in 2012
from "Sitting is Killing You? Move to New York"

Artsy has now grown past 140 team members and our Engineering organization is a nimble 25. We've recently performed a large organizational change (I highly recommend reading "The Secret(s) to Company Re-Orgs"), so this is a good time to describe our updated Engineering organization, starting from the top - Artsy as a company and business.

The Company

Artsy’s mission is to make all the world’s art accessible to anyone with an Internet connection. We are a resource for art collecting and education. Artsy features the world’s leading galleries, museum collections, foundations, artist estates, art fairs, and benefit auctions, all in one place. Our growing database of 350,000 images of art, architecture, and design by 50,000 artists spans historical, modern, and contemporary works, and includes the largest online database of contemporary art. Artsy is used by art lovers, museum-goers, patrons, collectors, students, and educators to discover, learn about, and collect art.

The Artsy Businesses

Artsy has 3 businesses: Listings, Marketplace and Content.

Listings: Artsy gallery partners pay a flat monthly subscription fee to list an unlimited number of artworks for sale, plus a host of other benefits. They do not pay a commission fee on sales made through Artsy.

Marketplace: In 2015 Artsy expanded into hosting commercial auctions on our platform. Much like our Listings business, we work with top auction houses. The latter pay commissions from sales. Check out current auctions on Artsy.

Content: We are also working on making Artsy a go-to platform for brands to co-create and distribute content that engages a global arts and culture audience. In 2015 we debuted our first sponsored content feature on Artsy, a series of 11 educational short films about the Venice Biennale in partnership with UBS (if anything, watch this amazing video).

A Product Engineering Organization

We think of Engineering as a service of the Product organization. Products serve customers and product teams serve businesses. Each product team may contribute to one or several businesses. To make our goals crystal clear, we developed Key Performance Indicators (KPIs) for each business. For example, churn is a KPI for the Listings business - a low churn shows how well we're serving our existing subscribers. Furthermore, we designed each product team to own all necessary resources to accomplish their goals. In some ways, our product teams operate like small start-ups.

Each product team consists of one or more Business People, a Product Owner (often a Product Manager), a Designer, an Engineering Lead and several Engineers.

Our product teams map directly into our businesses and inherit the same KPIs.

Partner Success: The Partner Success team focuses on products that serve the Listings business. These include our Content Management system and Artsy Folio, an iPad app used by our partners.

Auctions: The Auctions product team builds all auction systems across web and mobile.

Collector GMV: GMV stands for Gross Merchandising Volume, a measure of artworks traded on the platform. We have two collector product teams, web and mobile, focused on various customer experiences across all our web and mobile properties.

Publishing: The publishing team works on the platform used to produce and distribute all our online editorial content.

Practices

While there're many advantages of product teams operating independently, it's also very easy to create vertical inefficiencies. Multiple teams could choose to achieve similar outcomes in many different ways, creating a lot of redundant work and making it impossible for team members to move between organizations.

To address this problem we've created a separate Platform Engineering Team and Practices.

The Platform Engineering Team is responsible for systems and shared infrastructure that help product teams work smarter, scale our operations, and much more. Our Design team is similar in nature to Platform Engineering, creating a consistent visual language and user experience across all products.

Our Practices, specifically Web and Mobile, are run by a handful of experienced Engineers working independently and floating between product teams to build features, while evangelizing best practices of making software or our commitment to open-source at the same time. Engineerers on product teams may also belong to a practice - mobile engineers on the Auctions team are members of the Mobile practice, but don't report to the Director of Mobile.

Reporting Structure

We believe that in order to help our team members grow professionally, their manager must understand their work. Engineers report to Engineering Leads in product teams. Engineering and Engineering Practice Leads report to the Head of Engineering. Product Managers report to the Head of Product. Designers report to the Design Lead, who reports to the Head of Product. It's important to note that, while preserving top-down authority and responsibility, we try to practice bottom-up leadership - the job of team leads is to help individual contributors do their best work.

Conclusion

We have a very complex business, and we think our structure works well for a company that does many things at once. Your mileage may vary, so don't try to apply the same structure in your company just because this works for us! And always remember that evolving an organization is a disruptive process. It may yield better focus and can be transformational to a group. It may also produce the opposite effect, since moving individuals between teams is much more involved than drag-and-dropping a headcount in an organizational chart.

Public Speaking - Part 2: Where To Start?

Mon, 14 Mar 2016 11:00:00 +0000

So you’ve decided you’d like to give speaking a go, or perhaps you were always interested. By now you’re probably wondering where to start.

There are various options depending on what you’re looking for. Would you prefer a smaller, intimate audience or would you like to reach far and wide? Is the topic of your choice suited for a quick talk or would you rather discuss it at length? Let’s have a look.

In-house / Workplace Knowledge Share

Lots of workplaces dedicate some time to knowledge sharing nowadays (and if yours doesn’t, see if you can start one!). They can be technical, for instance at Artsy we host a technical Lunch and Learn weekly. They could also be on any topic, like meditation. Anywhere between 5 and 15 minutes in length is common, and they are a perfect opportunity to talk about things you know well. This could be centred around your day to day work, spreading the knowledge to decrease the bus factor, or something from your personal life. I’ve given a talk on colour theory in painting once.

If you have a workplace you feel comfortable at, this is definitely a good place to start.

One of the key elements in public speaking that is often forgotten is the fact that the audience wants you to succeed. They’re not there to poke holes or boo you off stage. They are curious to see what you have to say and learn from you. Give them that opportunity.

Even if your goal is towards speaking at bigger events, any chance at practicing and putting together a well flowing talk is good and shouldn’t be ignored.

Local meet-ups

If you’re in a city that has a thriving meet-up scene, you may want to put your name forward to speak on a certain topic. A UK meet-up, NSLondon, is a great example of this. Many different members of the community have spoken, and it’s created a lovely atmosphere where it feels like you’re exchanging interesting tidbits of information continuously. Also for newcomers it’s created a welcoming atmosphere, as the people speaking are often people they know or “just like them”.

If you have a meet-up with a similar positive vibe, there’s no reason not to have a chat with the organisers and see what the next steps would be. It might even be well worth practicing a talk here, for when you’ve got a bigger event coming up and you would like feedback. Bare in mind, the audience wants you to succeed!

Sidenote — if your city does not (yet) have a great meet-up, it’s well worth starting one.

Conferences

Often considered the most intimidating of all. People have purchased tickets and possibly travelled from far. The audience is usually in the hundreds, occasionally even more than a thousand. Even the most experienced speakers can get a bit nervous for this.

Funnily enough, my first ever talk, since starting out as a developer, was at a conference. It happened to have a very friendly atmosphere and really wasn’t that scary. I can’t stress enough that, yes, the audience wants you to succeed. I remember talking through my introduction and seeing all the curious, attentive faces. They were there because they were interested. They cared for what I had to say.

I will say that this doesn’t necessarily mean you should go talk about anything your heart desires. Ultimately the attendees are there to learn, so it’s only fair that as speakers you’d tailor your presentation towards your audience. But more on that in Part 3.

To be considered, often conference organisers ask people to submit a CfP (Call for Papers / Call for Proposals). This is your chance to submit details on what you’d like to present on, although they may give you suggestions. You usually want to include a preliminary talk title, an abstract, and a bit of background on yourself. If you’ve done any talks before and they happen to have been recorded, it’s worth including the video or otherwise previous slidedecks.

As for how CfPs then get chosen depends on the conference. Most of the time the organisational committee selects talks from the proposal list. Some conferences have an independent panel review anonymised proposals or have a system in place where the community votes. Once it’s been decided, they will get back in touch with you.

Usually conferences are swarmed with CfPs so please don’t be discouraged if it takes a few tries to get picked. It’s understandable to feel rejected and give up, but bare in mind that a friend of mine felt this way yet kept applying. He got his break at NSSpain 2014, and now is incredibly active in the San Francisco Swift meet-up scene. All of this got the ball rolling and now he's given talks all around the world. You might even have heard of him.

Lightning talks

If a CfP is a bit too much to prepare at the moment (we’re all busy) or you didn’t get in, another option is to give a lightning talk if the conference of your choice has slots. When done well, they are great.

A lightning talk is usually capped at 5 minutes, and gives you the time and space to cover one thing well. The best ones I’ve heard, have had one main message to convey and did so excellently.

They require a bit of planning as you want to be concise, but will be done before you know it and gives the audience a great point of reference to engage with you. Not to mention that sometimes you might get asked to do a full talk based off these.

Preparing content

Choosing to publicly speak and where is only half the battle. Deciding the content, formulating an abstract, talk title, and slides are not trivial. But fear not, Part 3 in this series will have you covered. Stay tuned!

Public Speaking - Part 1: Is It For Me?

Wed, 09 Mar 2016 11:00:00 +0000

At Artsy, sharing knowledge is heavily encouraged and so we write our code in the open, document using blog posts, and speak about our experiences. Many have bumped into us at various places around the world. And so I often get the question: “How did you get started? I’m interested in speaking too”.

In the name of sharing experiences with others, I can’t encourage this enough. Unfortunately though, public speaking is still considered man’s biggest fear.

I’d like to share with you the benefits of public speaking, tips on how to get started, and how to give great presentations.

Why do it?

Communication

Without necessarily realising, you’re publicly speaking all the time. At the heart of it, it’s the act of communicating and expressing your ideas and viewpoints for others to understand.

It could be as simple as ordering your morning coffee or as important as trying to convince your team that they should use a new technology. Regardless of the context, it involves restructuring your thoughts into words and metaphors that you think others can relate to in order for them to understand your concepts.

Public speaking is a skill that is always good to improve on. Misunderstandings happen all the time, and at the heart of that is often poor communication.

I know people have refrained from speaking up in meetings at work, because they struggle with speaking in front of others. There’s no need for everyone to be a keynote speaker at a conference, but if it’s hindering you in your career, it may be worth practicing. Everyone should feel empowered to call a meeting, participate in discussions, or ask questions at an all hands.

Learning

Another reason giving talks is 👍🏽 is that it will allow you to learn more fully. One of the best ways to learn is by teaching others. You grasp ideas better yourself and in order to communicate them properly, you get into the habit of restructuring your ideas and concepts.

Unfortunately, people often also consider this the blocker to public speaking. Not only are you afraid you’ll accidentally make a fool of yourself (“what if I trip?”) but also that it will be apparent that you don’t know something well enough. The only way to get over this is by doing it.

Chances are that you are actually very knowledgeable in certain fields, you just perceive that as normal. “Yeah, but that’s not interesting… everyone knows about that”. And I can bet that, well, probably not everyone knows about that. Definitely not as much as you might actually do.

We all have our strengths. This is the time to play on them. We can’t be experts in both Core Image, Core Animation, and the Objective C runtime, all the while knowing everything about Swift Protocols. Pick your slice from a much wider scope. It doesn’t need to be a full framework, even just a specific use case of it, like background transfer services.

Furthermore, see it as a learning opportunity. Speak about a topic that truly interests you and take this time to uncover things you’ve always wanted to know. It does not require you to be an expert up front — sharing knowledge gives you the chance to become one.

For example, I wanted to give a talk on the beauty of design and why beautiful things “just work”. I took this chance to read papers and books on the field of positive psychology and design, learning all kinds of fun new facts. Others have shared with me also that it wasn’t until they decided to write or speak about certain API that they fully got to understand all the ins and outs.

Ok you got me interested… now what?

That's great!

Next you'd probably want to figure out where you'd like to speak and how to prepare a good talk. This will be covered in the next two posts, so stay tuned.

Code Injection for Xcode

Sat, 05 Mar 2016 12:09:00 +0000

I have been writing code for roughly a decade. A large chunk of that time has been sitting waiting for my project to compile. It's a nice excuse to practice sword fighting in the office, but really, deep down. It's frustrating. It's so easy to become nerd-sniped when you wait for a long time.

As we integrate Swift into our projects, I've been seeing our compile times increase. So, I took some time to look at ways to improve this. The best option, so far, has been dynamic code injection via Injection Plugin for Xcode. In a gist: This means that we don't recompile and re-launch, instead we inject new bits of code into a running application. This reduced the compile cycle on Eigen from 7 seconds to 1 second.

I took some time over the weekend to try and put together a video showing how I used code injection on a trivial app to create a view controller in code. It covers the technique I've started using in Eigen and talks a little bit about how the pieces come together.

Jump to YouTube for the video, or click more for a smaller inline preview.

Being a Better Programmer When You're Actually Lazy.

Wed, 02 Mar 2016 12:09:00 +0000

I juggle a bunch of projects, both in Artsy and in the Open Source community. If you don't work with me directly, you'd be mistaken for believing that I was an organized person. I'm pretty far from that, and don't really plan on changing that.

However, I work with other people and very strongly believe that programming is mostly a social problem once you're good enough at writing code. It'd be hypocritical of me to not improve the people process side, so I try to automate processes that makes me a better team-mate.

I'm going to cover four things I've worked on lately to improve this: Danger, GitHub-Clippers and improving how I write commits and prefixing my name on branches.

Danger

Danger is a tool I co-created with a friend (Felix Krause), and it's namesake, Gem "Danger" McShane. It came out of frustration that we couldn't easily hold ourselves accountable to better team processes. Requiring a code-reviewer to also remember details like "Add a CHANGELOG Entry" isn't much to ask, but it is "Yet Another Thing To Remember" for both the submitter and reviewer.

It's turning into a really important part of our code-review, and the ideas it generates once we had it in place make it fun to add new rules. It means we can fail fast, and not have to think about process so much. Danger will tell us if we've missed something.

I expect to write a more serious post on Danger once it's more fleshed out. For now though, the README covers what it does well.

Clippers

In every big team I operate in, other people care about keeping the repo clean of merged branches. I totally respect their opinion, but it's so low on things I care about that I just don't register the "Delete Branch" button on a GitHub pull request. I'd rather be finding a good response GIF.

So I created a Safari Extension that handles automatically deleting branches on specific repos for me. It's not a biggie, it's not fancy, it's under a hundred lines of code - but it automates something that annoyed others about my behavior. That counts for something.

Commit Automation

I write reasonable commit messages, they're not amazing, they're not terrible. They're just, alright. I wanted to start trying to hold everyone accountable for doing better, so I advocated for copying the person with the best commit style on our team.

Their style is to have commits in a format like [Context] Thing I did. - it is much better that Thing I did.. So I looked into how I could automate this, because I would very quickly forget to do this. Here's what I did:

// Helper function to get the branch info
function git_branch_info() {
  ref=$(command git symbolic-ref HEAD 2> /dev/null) || \
  ref=$(command git rev-parse --short HEAD 2> /dev/null) || return
  echo "${ref#refs/heads/}"
}

function branch() {
  git checkout master;
  git pull upstream master;
  git checkout -b $1
  git config branch.$1.description $2
}

function commit() {
  local BRANCH=$(git_branch_info)
  local INFO=$(git config branch.$(echo $BRANCH).description)
  git commit -m "[$(echo $INFO)] $argv"
}

// And if I forget to set my context
function context() {
  local BRANCH=$(git_branch_info)
  git config branch.$(echo $BRANCH).description $1
}

Or if you're a fish user like me, this gist.

I created two shell functions, one that makes a branch that includes a context type. So for example, say I'm working on artwork notifications, I'd start a new branch with $ branch artwork_notifications Notifications. This saves the context as Notifications on the git branch metadata. Then everytime I want to commit my changes, I use $ commit This is the thing I changed. - and it will be prefixed with [Notifications]. It makes it easier for someone looking through the history to have an idea about the context, and makes me feel like I'm improving my process without remembering the context.

Branch Prefixes

We use a Makefile in all our projects to try and help automate per-project simple tasks like running mogenerator, updating storyboard identifiers and updating embedded resources.

I also applied some standard make commands in our projects so that I can prefix my branches with my name.

LOCAL_BRANCH = $(shell git rev-parse --abbrev-ref HEAD)
BRANCH = $(shell echo host=github.com | git credential fill | sed -E 'N; s/.*username=(.+)\n?.*/\1/')-$(shell git rev-parse --abbrev-ref HEAD)

pr:
  if [ "$(LOCAL_BRANCH)" == "master" ]; then echo "In master, not PRing"; else git push upstream "$(LOCAL_BRANCH):$(BRANCH)"; open "https://github.com/artsy/eigen/pull/new/artsy:master...$(BRANCH)"; fi

push:
  if [ "$(LOCAL_BRANCH)" == "master" ]; then echo "In master, not pushing"; else git push upstream $(LOCAL_BRANCH):$(BRANCH); fi

fpush:
  if [ "$(LOCAL_BRANCH)" == "master" ]; then echo "In master, not pushing"; else git push upstream $(LOCAL_BRANCH):$(BRANCH) --force; fi

This works by some funky shell work to pull out your current branch into LOCAL_BRANCH, then to do the same thing but prefixed with your login name for BRANCH. Then the make commands handle pushing to the server. This means that everyone in the team can provide have logically named branches without having to have their local repo filled with [my_name]-thing branches.

On-going

This is a work in progress, as the mobile team grows, we need to add more process when it's appropriate. This doesn't mean that we have to sacrifice speed, and we can continue thinking about the problem at hand rather than devoting energy to process.

It's a time trade-off that has worked out well for me so far, and I'd love to know other people's hacks for having useful process, but automating it so that it's not considered overhead.

Code Review: Energy Sync

Fri, 12 Feb 2016 12:09:00 +0000

We are slowly trying to do high-level code-review views for all of our iOS apps. So far, we've covered Eidolon and Emergence and now Energy. This is the second part of the Energy code review. The first part covers the the critical codepaths that go from the App's launch to sending an email, which is the main use-case for the app. This video covers how Folio does sync between the Artsy API and the app.

Sync is a complex problem. This video covers our old techniques, how we changed them, the underlying abstractions we use now and how we can test each component individually. It's an hour long, and it's a little computer-sciencey. So I think people who have shipped some small apps would get a lot out of it.

Jump to YouTube for the video, or click more for a smaller inline preview.

Code Review: Energy overview

Thu, 11 Feb 2016 11:09:00 +0000

We are slowly trying to do high-level code-review views for all of our iOS apps. So far, we've covered Eidolon and Emergence. Folio is an app that's shipped to the App Store in early 2012, it's used by our Partners to showcase their works offline, at fairs and on the go. If you want the full spiel, check out this microsite.

This video talks through a lot of the critical codepaths that go from the App's launch to sending an email, which is the main use-case for the app. We have another video coming up which exclusively covers how Folio does sync between the Artsy API and the app.

Jump to YouTube for the video, or click more for a smaller inline preview.