| title | description |
|---|---|
Engineering Team Introduction |
A brief introduction |
Depends on the person/where they are located! We try to schedule meetings at times that are amenable to people being remote (from Amsterdam to Seattle on the engineering team), so they'll usually happen in the middle of the day EST.
Ask your mentor/manager what their general work hours are. Artsy has no policy around this, so use your judgment and be open with your team about when you expect to be available.
Artsy has an open vacation policy. This doesn't mean "don't take vacation." Please take time off. Most people take off for bank holidays.
Join the Design/Product OOO calendar and use that to set when you know you'll be out of the office or unavailable.
Most of our day-to-day business is conducted in Slack. Teams, offices, and common concerns frequently have their
own channels. For more information on our usage of Slack, see /culture/slack.md.
See the events list for descriptions of our recurring, engineering-wide events. Look at the Engineering - Open Meetings calendar to see when they are scheduled and feel free to add yourself to any (or just show up).
We have an engineering team-wide standup on Mondays at 12:00 p.m. Eastern where we:
- Share any team updates
- Mention significant project milestones or new repositories
- Ask for help if we're blocked or need input from a different team
- Plan the week's knowledge share
- Recognize and congratulate each other for significant accomplishments
The standup is fully documented here.
- Slack: If you know what team could potentially help you, browse the channels in Slack to find the most relevant place to ask your question. If you aren't sure, all engineers are in #dev 🔒 and #dev-help🔒 is a good place for general questions.
- Ask Your Neighbor: Everyone is friendly. Don't hesitate to reach out to the people around you for even the most basic of questions.
- Check Atlas: Many company-wide resources and questions are addressed in atlas.artsy.net 🔒.
Some team members have backgrounds in art, but of course not all. /resources/art.md has some useful links if you want to read more about the art world, or keep up with the latest news.
At Artsy, we <3 open source and encourage you to become part of the community. Here is a list of some open source technologies we currently use.
Read @dblock's blog post on Becoming Open Source by Default.
Read this article by the mobile team on the culture of open source at Artsy and their reasons behind open-sourcing our mobile app.
Orta also wrote a blog post on the mechanics behind open-sourcing Eigen.
Artsy stores source code on GitHub. Make sure you have an account and are part of the Artsy organization. If you can't visit this page 🔒, then you don’t have the right access. Your mentor can get you sorted out.
Our projects use physics terms as code names, starting with Gravity 🔒 (inspired by Zachary Coffin's "Temple of Gravity").
See the engineering projects map 🔒 for a comprehensive list of our (many) repos and associated teams. It can be a bit overwhelming, so here are some important ones:
- Gravity 🔒: Artsy's main API
- Force: Artsy web site (www.artsy.net)
- Eigen: iOS app
- Volt 🔒: Content Management system for partners
Many applications depend on Amazon Web Services. Your mentor or anyone else in Engineering can set you up with an IAM profile within our organization's account (see instructions 🔒).
Read @orta's blog post describing our stack in 2017, which evolved from our stack in 2015, which evolved from our tech stack at launch in 2012, which evolved from a Rails monolith.
See apis 🔒 and domain models 🔒 in Potential.
The engineering team playbooks discuss why we make the technical and non-technical decisions we do.
The scripts/setup 🔒 script will install common dependencies for local development (homebrew, Ruby, etc.).
Projects can provide their own setup scripts that build on this common foundation. See Gravity's script/setup 🔒 as an example.
Most projects use the hokusai wrapper for testing, configuration, and
deployment to kubernetes. The hokusai dev ... commands simplify local development using Docker.
Most engineers use Visual Studio Code, but feel free to use whatever makes you
most comfortable. We recommend that projects include a .vscode folder with settings, and an
extensions.json so
that developers can have the same experience. For example:
A lot of engineers have moved from Sublime Text or vim, if you want to retain your keyboard shortcuts / modes, you can find a list of extensions handling that.
As all of our code is housed on GitHub, we make contributions through pull requests.
Read more in the engineer workflow playbook or see this
step-by-step guide 🔒. If you're unfamiliar
with Git, check out this short tutorial on basic git commands (such as git status,
git commit, and git push).
Once your pull request is merged, we use services like CircleCI to run the full test suite to make sure code changes did not break existing features.
Many of our apps automatically deploy to a staging environment once CI (continuous integration) succeeds. Production deploys vary by project, but are usually documented in project READMEs.
We try to deploy early and often. You don't need permission to deploy--just announce in #dev slack channel in case the team has any concerns. Seriously, see this slack message 🔒.
More about continuous improvement.
Teams at Artsy work with product management via Jira 🔒. Teams tend to work in 2 week sprints, with a planning meeting at the start and a review/retrospective at the end.
PDDE-wide, the 2nd Friday of each sprint is "Future Friday." This is a lightweight process focused on collecting ideas about longer-term opportunities during the course of day-to-day work.
Conversations can be labeled with #ff so they're find-able later. When Friday comes (if you're so compelled), choose a direction to explore/experiment and report back any results at end-of-day. Participation is optional and collaborations are encouraged.