Blog
diff --git a/_posts/2012-03-23-simplifying-model-level-json-versioning-with-mongoid-cached-json.markdown b/_posts/2012-03-23-simplifying-model-level-json-versioning-with-mongoid-cached-json.markdown index 5b7ae76e6e..d2767d3b6d 100644 --- a/_posts/2012-03-23-simplifying-model-level-json-versioning-with-mongoid-cached-json.markdown +++ b/_posts/2012-03-23-simplifying-model-level-json-versioning-with-mongoid-cached-json.markdown @@ -86,4 +86,4 @@ class Person end ``` -With the [mongoid-cached-json](http://github.com/dblock/mongoid-cached-json) gem you also get caching that respects JSON versioning, for free. Read about it [here](http://artsy.github.com/blog/2012/02/20/caching-model-json-with-mongoid-cached-json/). +With the [mongoid-cached-json](http://github.com/dblock/mongoid-cached-json) gem you also get caching that respects JSON versioning, for free. Read about it [here](https://artsy.github.com/blog/2012/02/20/caching-model-json-with-mongoid-cached-json/). diff --git a/_posts/2012-05-27-using-jenkins-for-ruby-and-ruby-on-rails-teams.markdown b/_posts/2012-05-27-using-jenkins-for-ruby-and-ruby-on-rails-teams.markdown index 5766760768..2953f84ced 100644 --- a/_posts/2012-05-27-using-jenkins-for-ruby-and-ruby-on-rails-teams.markdown +++ b/_posts/2012-05-27-using-jenkins-for-ruby-and-ruby-on-rails-teams.markdown @@ -44,7 +44,7 @@ bundle install bundle exec rake ``` -Our default Ruby project Rake task is `test:ci`. We run Jasmine and Capybara tests using a real browser, so we need to redirect all visible output to an X-Windows Virtual Frame Buffer ([XVFB](http://www.xfree86.org/4.0.1/Xvfb.1.html)). This can be done by setting an `ENV` variable inside a Rake task. Our test target also [organizes our tests in suites](http://artsy.github.com/blog/2012/05/15/how-to-organize-over-3000-rspec-specs-and-retry-test-failures/). +Our default Ruby project Rake task is `test:ci`. We run Jasmine and Capybara tests using a real browser, so we need to redirect all visible output to an X-Windows Virtual Frame Buffer ([XVFB](http://www.xfree86.org/4.0.1/Xvfb.1.html)). This can be done by setting an `ENV` variable inside a Rake task. Our test target also [organizes our tests in suites](https://artsy.github.com/blog/2012/05/15/how-to-organize-over-3000-rspec-specs-and-retry-test-failures/). ``` ruby namespace :test do diff --git a/_posts/2012-07-10-on-demand-jenkins-slaves-with-amazon-ec2.markdown b/_posts/2012-07-10-on-demand-jenkins-slaves-with-amazon-ec2.markdown index d1761d99fb..075857dcd2 100644 --- a/_posts/2012-07-10-on-demand-jenkins-slaves-with-amazon-ec2.markdown +++ b/_posts/2012-07-10-on-demand-jenkins-slaves-with-amazon-ec2.markdown @@ -7,7 +7,7 @@ categories: [Jenkins, Testing, Continuous Integration, EC2] author: [joey, frank] --- -The [Artsy](http://artsy.net) team faithfully uses [Jenkins](http://jenkins-ci.org) for continuous integration. [As we've described before](http://artsy.github.com/blog/2012/05/27/using-jenkins-for-ruby-and-ruby-on-rails-teams/), our Jenkins master and 8 slaves run on Linode. This arrangement has at least a few drawbacks: +The [Artsy](http://artsy.net) team faithfully uses [Jenkins](http://jenkins-ci.org) for continuous integration. [As we've described before](https://artsy.github.com/blog/2012/05/27/using-jenkins-for-ruby-and-ruby-on-rails-teams/), our Jenkins master and 8 slaves run on Linode. This arrangement has at least a few drawbacks: * Our Linode servers are manually configured. They require frequent maintenance, and inconsistencies lead to surprising build failures. * The fixed set of slaves don't match the pattern of our build jobs: jobs get backed up during the day, but servers are mostly unused overnight and on weekends. diff --git a/_posts/2012-10-10-artsy-technology-stack.markdown b/_posts/2012-10-10-artsy-technology-stack.markdown index a0046b515f..6adfedf0db 100644 --- a/_posts/2012-10-10-artsy-technology-stack.markdown +++ b/_posts/2012-10-10-artsy-technology-stack.markdown @@ -62,7 +62,7 @@ The Artsy CMS and the Admin system are two newer projects and serve the needs of Folio Partner App ----------------- -Artsy makes a free iOS application, called [Folio](http://artsy.github.com/blog/categories/ios/), which lets our partners display their inventory at art fairs. +Artsy makes a free iOS application, called [Folio](https://artsy.github.com/blog/categories/ios/), which lets our partners display their inventory at art fairs. Folio is a native iOS implementation. The interface is heavily skinned UIKit with CoreData for storage. Our network code was originally a thin layer on top of NSURLConnection, but for our forthcoming update, we’ve rewritten it to use [AFNetworking](https://github.com/AFNetworking/AFNetworking/). We manage external dependencies with [CocoaPods](https://github.com/CocoaPods/CocoaPods). diff --git a/_posts/2013-04-01-an-easter-egg-for-curl.markdown b/_posts/2013-04-01-an-easter-egg-for-curl.markdown index e6aed1e13f..e2b93dc9ea 100644 --- a/_posts/2013-04-01-an-easter-egg-for-curl.markdown +++ b/_posts/2013-04-01-an-easter-egg-for-curl.markdown @@ -30,7 +30,7 @@ curl https://api.artsy.net/api/v1/system/up?access_token=10013 -v < Content-Type: application/json < Content-Length: 76 -{ "error" : "Inspiration from the Engineering team at http://artsy.github.com" } +{ "error" : "Inspiration from the Engineering team at https://artsy.github.com" } ``` What?! **401 Broadway**? See, our office address is *401 Broadway, 10013, New York, NY*. We just tried to add a more developer-friendly way to find us in the New York grid. And here's the view from our 25th floor office - that's SOHO right below us and the Empire State Building a bit North. @@ -65,7 +65,7 @@ class ApiAuthMiddleware < Grape::Middleware::Base def before if access_token == "10013" throw :error, - message: 'Inspiration from the Engineering team at http://artsy.github.com', + message: 'Inspiration from the Engineering team at https://artsy.github.com', status: 2600 else ... diff --git a/_posts/2013-06-14-writing-headless-backbone-tests-with-node-dot-js.markdown b/_posts/2013-06-14-writing-headless-backbone-tests-with-node-dot-js.markdown index 8e393fe070..adea2eb856 100644 --- a/_posts/2013-06-14-writing-headless-backbone-tests-with-node-dot-js.markdown +++ b/_posts/2013-06-14-writing-headless-backbone-tests-with-node-dot-js.markdown @@ -13,7 +13,7 @@ Write fast, headless, tests for Backbone using Node.js. See this project as an e ## A Brief History -Artsy is mostly a thick client [Backbone](http://backbonejs.org/) app that sits on [Rails](http://rubyonrails.org/) and largely depends on [Capybara](http://jnicklas.github.io/capybara/) ([Selenium](http://docs.seleniumhq.org/) backed bot that clicks around Firefox) for testing it's javascript. This leads to some seriously brittle and slow integration tests. [Despite being able to wrangle Capybara](http://artsy.github.io/blog/2012/02/03/reliably-testing-asynchronous-ui-w-slash-rspec-and-capybara/) to do most of our client-side testing, we knew there must be a better way. +Artsy is mostly a thick client [Backbone](http://backbonejs.org/) app that sits on [Rails](http://rubyonrails.org/) and largely depends on [Capybara](http://jnicklas.github.io/capybara/) ([Selenium](http://docs.seleniumhq.org/) backed bot that clicks around Firefox) for testing it's javascript. This leads to some seriously brittle and slow integration tests. [Despite being able to wrangle Capybara](https://artsy.github.io/blog/2012/02/03/reliably-testing-asynchronous-ui-w-slash-rspec-and-capybara/) to do most of our client-side testing, we knew there must be a better way. When building a CMS app for our gallery partners to manage their Artsy inventory, we built a new Backbone app on top of [node.js](http://nodejs.org/). The result was a headless test suite that runs around 60 times faster. diff --git a/_posts/2013-08-27-introduction-to-aws-opsworks.markdown b/_posts/2013-08-27-introduction-to-aws-opsworks.markdown index 8279276af4..5e10d97434 100644 --- a/_posts/2013-08-27-introduction-to-aws-opsworks.markdown +++ b/_posts/2013-08-27-introduction-to-aws-opsworks.markdown @@ -30,7 +30,7 @@ Conversely, OpsWorks offers higher-level control than [CloudFormation](https://a {% include expanded_img.html url="/images/2013-08-27-introduction-to-aws-opsworks/aws_control.png" title="How OpsWorks fits in AWS offerings" %} -Historically, Artsy delegated dev-ops concerns to Heroku. They worried about infrastructure, freeing us to focus on our application's higher-level goals. Increasingly though, we were forced to work around limitations of the platform's performance, architecture, and customizability. (We even blogged about it [here](http://artsy.github.io/blog/2012/01/31/beyond-heroku-satellite-delayed-job-workers-on-ec2/), [here](http://artsy.github.io/blog/2012/11/15/how-to-monitor-503s-and-timeout-on-heroku/), [here](http://artsy.github.io/blog/2012/12/13/beat-heroku-60-seconds-application-boot-timeout-with-a-proxy/), [here](http://artsy.github.io/blog/2013/02/01/master-heroku-command-line-with-heroku-commander/), and [here](http://artsy.github.io/blog/2013/02/17/impact-of-heroku-routing-mesh-and-random-routing/).) Rather than continue to work against the platform, we turned to OpsWorks for greater flexibility while keeping administrative burden low. +Historically, Artsy delegated dev-ops concerns to Heroku. They worried about infrastructure, freeing us to focus on our application's higher-level goals. Increasingly though, we were forced to work around limitations of the platform's performance, architecture, and customizability. (We even blogged about it [here](https://artsy.github.io/blog/2012/01/31/beyond-heroku-satellite-delayed-job-workers-on-ec2/), [here](https://artsy.github.io/blog/2012/11/15/how-to-monitor-503s-and-timeout-on-heroku/), [here](https://artsy.github.io/blog/2012/12/13/beat-heroku-60-seconds-application-boot-timeout-with-a-proxy/), [here](https://artsy.github.io/blog/2013/02/01/master-heroku-command-line-with-heroku-commander/), and [here](https://artsy.github.io/blog/2013/02/17/impact-of-heroku-routing-mesh-and-random-routing/).) Rather than continue to work against the platform, we turned to OpsWorks for greater flexibility while keeping administrative burden low. ## OpsWorks Overview diff --git a/_posts/2014-01-30-isolating-spurious-and-nondeterministic-tests.markdown b/_posts/2014-01-30-isolating-spurious-and-nondeterministic-tests.markdown index 7729a0fbdd..b9f7faf25d 100644 --- a/_posts/2014-01-30-isolating-spurious-and-nondeterministic-tests.markdown +++ b/_posts/2014-01-30-isolating-spurious-and-nondeterministic-tests.markdown @@ -13,7 +13,7 @@ These failures might be due to slight timing differences or lack of proper isola ## The Quarantine -We've been [automatically retrying failed tests](http://artsy.github.io/blog/2012/05/15/how-to-organize-over-3000-rspec-specs-and-retry-test-failures/), with some success. However, these problems tend to get worse. (If you have 10 tests that each have a 1% chance of failing, roughly 1 in 10 builds will fail. If you have 50, 4 in 10 builds will fail.) +We've been [automatically retrying failed tests](https://artsy.github.io/blog/2012/05/15/how-to-organize-over-3000-rspec-specs-and-retry-test-failures/), with some success. However, these problems tend to get worse. (If you have 10 tests that each have a 1% chance of failing, roughly 1 in 10 builds will fail. If you have 50, 4 in 10 builds will fail.) Martin Fowler offers the most compelling thoughts on this topic in [Eradicating Non-Determinism in Tests](http://martinfowler.com/articles/nonDeterminism.html). (Read it, really.) He suggests quarantining problematic tests in a separate suite, so they don't block the build pipeline. diff --git a/_posts/2014-04-02-refactoring-infrastructure.markdown b/_posts/2014-04-02-refactoring-infrastructure.markdown index 3be5e03c92..c8dcdd0e22 100644 --- a/_posts/2014-04-02-refactoring-infrastructure.markdown +++ b/_posts/2014-04-02-refactoring-infrastructure.markdown @@ -41,7 +41,7 @@ Once the new app was feature-complete, we removed the proxying layer and updated New hosting environment --- -When we [switched hosting providers](http://artsy.github.io/blog/2013/08/27/introduction-to-aws-opsworks/) for our main application, it required changes to _many_ related tools and services (for logs, deploys, background queues, etc.). To mitigate risk, we set up a "double-deploy" to the legacy and new environments as soon as the basic elements were in place. The environments ran the same code and shared a data store. First, we targeted the new environment from only a few internal apps. As we surfaced and fixed bugs, we directed more client applications away from the old, eventually winding it down altogether. The process was spread over months, but since each individual change was small and low-risk, we were confident and could adjust course as necessary. +When we [switched hosting providers](https://artsy.github.io/blog/2013/08/27/introduction-to-aws-opsworks/) for our main application, it required changes to _many_ related tools and services (for logs, deploys, background queues, etc.). To mitigate risk, we set up a "double-deploy" to the legacy and new environments as soon as the basic elements were in place. The environments ran the same code and shared a data store. First, we targeted the new environment from only a few internal apps. As we surfaced and fixed bugs, we directed more client applications away from the old, eventually winding it down altogether. The process was spread over months, but since each individual change was small and low-risk, we were confident and could adjust course as necessary. Full application rewrite --- diff --git a/_posts/2014-04-24-generating-notifications-and-personalized-emails-efficiently.markdown b/_posts/2014-04-24-generating-notifications-and-personalized-emails-efficiently.markdown index ad83dd2fc2..4c54fe0d2b 100644 --- a/_posts/2014-04-24-generating-notifications-and-personalized-emails-efficiently.markdown +++ b/_posts/2014-04-24-generating-notifications-and-personalized-emails-efficiently.markdown @@ -7,7 +7,7 @@ categories: [Ruby, Email, CSS, HTML] author: matt --- -We recently launched a new personalized email here at [Artsy](https://artsy.net) that features content that a given user might find interesting. The goal of this post is to describe how we built a backend system that efficiently generates these e-mails for all our users. I'll talk about the first, naive implementation that had performance problems right away, and how the second implementation (currently in production) solved those issues, and whose behavior at scale is well-defined and understood. I won't go into the details of the design and layout of the mail itself and how we render the content - there are several earlier blog posts that deal with those: [Presenters and Memoization](http://artsy.github.io/blog/2014/03/18/presenters-and-memoization-moving-logic-out-of-templates/), [Pinterest-style Layouts](http://artsy.github.io/blog/2014/03/17/ruby-helper-to-group-artworks-into-a-pinterest-style-layout-for-email/) and [Email Layouts and Responsiveness](http://artsy.github.io/blog/2014/03/17/some-tips-for-email-layout-and-responsiveness/). +We recently launched a new personalized email here at [Artsy](https://artsy.net) that features content that a given user might find interesting. The goal of this post is to describe how we built a backend system that efficiently generates these e-mails for all our users. I'll talk about the first, naive implementation that had performance problems right away, and how the second implementation (currently in production) solved those issues, and whose behavior at scale is well-defined and understood. I won't go into the details of the design and layout of the mail itself and how we render the content - there are several earlier blog posts that deal with those: [Presenters and Memoization](https://artsy.github.io/blog/2014/03/18/presenters-and-memoization-moving-logic-out-of-templates/), [Pinterest-style Layouts](https://artsy.github.io/blog/2014/03/17/ruby-helper-to-group-artworks-into-a-pinterest-style-layout-for-email/) and [Email Layouts and Responsiveness](https://artsy.github.io/blog/2014/03/17/some-tips-for-email-layout-and-responsiveness/).  @@ -209,7 +209,7 @@ def notifiable? end ``` -And...that's basically it! Throughout the week as partners are uploading their shows/fair booths/artworks, these records are being opportunistically written to that day's notification collection, in a performant and scalable fashion. Then when we want to send you a personalized email, we pull all your appropriate notifications via the ```get``` routine in our ```NotificationService```, and primarily using the technique described in [Presenters and Memoization](http://artsy.github.io/blog/2014/03/18/presenters-and-memoization-moving-logic-out-of-templates/) we make sure we cache/memoize all such data. Using the tips in [Pinterest-style Layouts](http://artsy.github.io/blog/2014/03/17/ruby-helper-to-group-artworks-into-a-pinterest-style-layout-for-email/) and [Email Layouts and Responsiveness](http://artsy.github.io/blog/2014/03/17/some-tips-for-email-layout-and-responsiveness/) we can render this content and support various devices/email clients. We parallelize and batch the generation/sending of our e-mails as well. This whole system, from notification generation to actually emailing users, is running successfully and smoothly in production. +And...that's basically it! Throughout the week as partners are uploading their shows/fair booths/artworks, these records are being opportunistically written to that day's notification collection, in a performant and scalable fashion. Then when we want to send you a personalized email, we pull all your appropriate notifications via the ```get``` routine in our ```NotificationService```, and primarily using the technique described in [Presenters and Memoization](https://artsy.github.io/blog/2014/03/18/presenters-and-memoization-moving-logic-out-of-templates/) we make sure we cache/memoize all such data. Using the tips in [Pinterest-style Layouts](https://artsy.github.io/blog/2014/03/17/ruby-helper-to-group-artworks-into-a-pinterest-style-layout-for-email/) and [Email Layouts and Responsiveness](https://artsy.github.io/blog/2014/03/17/some-tips-for-email-layout-and-responsiveness/) we can render this content and support various devices/email clients. We parallelize and batch the generation/sending of our e-mails as well. This whole system, from notification generation to actually emailing users, is running successfully and smoothly in production. ### Next Steps diff --git a/_posts/2014-05-12-continuous-integration-for-service-oriented-architectures.markdown b/_posts/2014-05-12-continuous-integration-for-service-oriented-architectures.markdown index f3022e838b..567eeb53e6 100644 --- a/_posts/2014-05-12-continuous-integration-for-service-oriented-architectures.markdown +++ b/_posts/2014-05-12-continuous-integration-for-service-oriented-architectures.markdown @@ -276,8 +276,8 @@ This basic structure has accommodated dozens of test scenarios. We've extended i A caveat: with so many layers and dependencies involved, there are often spurious failures. We've picked up a few practices that help: -* [Automatic retries](http://artsy.github.io/blog/2012/05/15/how-to-organize-over-3000-rspec-specs-and-retry-test-failures/) -* [Quarantine for problematic tests](http://artsy.github.io/blog/2014/01/30/isolating-spurious-and-nondeterministic-tests/) +* [Automatic retries](https://artsy.github.io/blog/2012/05/15/how-to-organize-over-3000-rspec-specs-and-retry-test-failures/) +* [Quarantine for problematic tests](https://artsy.github.io/blog/2014/01/30/isolating-spurious-and-nondeterministic-tests/) * [Failure screenshots](https://github.com/mattheworiordan/capybara-screenshot) You can [grab the example code](https://github.com/joeyAghion/multiapp_example-tests). And make sure to let us know in the comments how _you_ approach testing across applications. diff --git a/_posts/2014-06-11-testing-core-data-migrations.markdown b/_posts/2014-06-11-testing-core-data-migrations.markdown index c31427587c..36a444e381 100644 --- a/_posts/2014-06-11-testing-core-data-migrations.markdown +++ b/_posts/2014-06-11-testing-core-data-migrations.markdown @@ -8,7 +8,7 @@ categories: [Testing, Objc, Cocoa, iOS] author: orta --- -The first time I released a patch release for [Artsy Folio](http://orta.github.io/#folio-header-unit) it crashed instantly, on every install. Turns out I didn't understand Core Data migrations, now a few years on I grok it better but I've still lived with the memories of that dark dark day. Because of this I've had an informal rule of testing migrations with all the old build of Folio [using chairs](http://artsy.github.io/blog/2013/03/29/musical-chairs/) the day before submitting to the app store. +The first time I released a patch release for [Artsy Folio](http://orta.github.io/#folio-header-unit) it crashed instantly, on every install. Turns out I didn't understand Core Data migrations, now a few years on I grok it better but I've still lived with the memories of that dark dark day. Because of this I've had an informal rule of testing migrations with all the old build of Folio [using chairs](https://artsy.github.io/blog/2013/03/29/musical-chairs/) the day before submitting to the app store. This time round, I've made vast changes to the Core Data models but skipped the manual work. Here's how: @@ -123,7 +123,7 @@ This meant it was very easy to quickly make tests that look like: ``` -This made it very cheap conceptually to make a new in-memory context and to be sure that the changes wouldn't affect the development data store. However, once I had this framework in place it became a pretty simple jump to taking the existing sqlite files that I already had around in my [chairs folder](http://artsy.github.io/blog/2013/03/29/musical-chairs/) and make to force a migration from that build to the latest managed object model. Here's the test suite in full: +This made it very cheap conceptually to make a new in-memory context and to be sure that the changes wouldn't affect the development data store. However, once I had this framework in place it became a pretty simple jump to taking the existing sqlite files that I already had around in my [chairs folder](https://artsy.github.io/blog/2013/03/29/musical-chairs/) and make to force a migration from that build to the latest managed object model. Here's the test suite in full: ```objc // diff --git a/_posts/2014-08-04-taking-a-snapshot-with-second-curtain.markdown b/_posts/2014-08-04-taking-a-snapshot-with-second-curtain.markdown index 3957fbdc6a..26edd261bb 100644 --- a/_posts/2014-08-04-taking-a-snapshot-with-second-curtain.markdown +++ b/_posts/2014-08-04-taking-a-snapshot-with-second-curtain.markdown @@ -53,7 +53,7 @@ Second Curtain relies on environment variables to get access to the S3 bucket where it stores the images. I planned on using Travis' system to [encrypt](http://docs.travis-ci.com/user/encryption-keys/) those credentials. It turns out, for very good reasons, encrypted environment variables are not available on pull requests created on forks of repositories. -This is a problem because of the way that [Artsy uses GitHub](http://artsy.github.io/blog/2012/01/29/how-art-dot-sy-uses-github-to-build-art-dot-sy/). +This is a problem because of the way that [Artsy uses GitHub](https://artsy.github.io/blog/2012/01/29/how-art-dot-sy-uses-github-to-build-art-dot-sy/). While it's not a problem for a closed-source repository to have (restrictive) access to an S3 bucket, it would be irresponsible to expose S3 credentials for an open-source project. I'm [working](https://github.com/AshFurrow/second_curtain/issues/5) diff --git a/_posts/2014-08-08-CocoaPods-Caching.markdown b/_posts/2014-08-08-CocoaPods-Caching.markdown index 3ecbc516af..12eb9702c1 100644 --- a/_posts/2014-08-08-CocoaPods-Caching.markdown +++ b/_posts/2014-08-08-CocoaPods-Caching.markdown @@ -7,7 +7,7 @@ categories: [iOS, Continuous Integration, Travis, Testing] author: orta --- -As [Ash said earlier](http://artsy.github.io/blog/2014/08/07/taking-a-snapshot-with-second-curtain/) we like using Continuous Integration. Today I spent a large amount of time migrating us to use the new CocoaPods caching system in Travis CI. To make up for my lost time I'm passing on what I've learned and also showing how we do CI at Artsy with Objective-C apps. If you're interested in how we do it in Swift, you can just check [Eidolon](https://github.com/artsy/eidolon). +As [Ash said earlier](https://artsy.github.io/blog/2014/08/07/taking-a-snapshot-with-second-curtain/) we like using Continuous Integration. Today I spent a large amount of time migrating us to use the new CocoaPods caching system in Travis CI. To make up for my lost time I'm passing on what I've learned and also showing how we do CI at Artsy with Objective-C apps. If you're interested in how we do it in Swift, you can just check [Eidolon](https://github.com/artsy/eidolon). @@ -179,6 +179,6 @@ This is nice and simple. It was built to use multiple travis build steps. This m
-We use a gem with a binary in [second_curtain](https://github.com/AshFurrow/second_curtain/), and this came with bundler caching issues in Travis. The solution was to ignore bundler and run `gem install second_curtain` each time. To increase the speed we also ensured that documentation is not being generated. If you are interested in what's going on with the `.netrc`, read my blog post on [Artsy's first Closed Source Pod](http://artsy.github.io/blog/2014/06/20/artsys-first-closed-source-pod/).
+We use a gem with a binary in [second_curtain](https://github.com/AshFurrow/second_curtain/), and this came with bundler caching issues in Travis. The solution was to ignore bundler and run `gem install second_curtain` each time. To increase the speed we also ensured that documentation is not being generated. If you are interested in what's going on with the `.netrc`, read my blog post on [Artsy's first Closed Source Pod](https://artsy.github.io/blog/2014/06/20/artsys-first-closed-source-pod/).
We will continue pushing the state of the art in iOS deployment, in building our own tools and using everything available to increase developer happiness. If you're into this we're always looking to hire people with a good open source track record or street smarts. Here's [the jobs page](https://artsy.net/job/mobile-engineer).
diff --git a/_posts/2014-09-05-we-open-sourced-our-isomorphic-javascript-website.markdown b/_posts/2014-09-05-we-open-sourced-our-isomorphic-javascript-website.markdown
index 7bda6c7743..2a60b6b02c 100644
--- a/_posts/2014-09-05-we-open-sourced-our-isomorphic-javascript-website.markdown
+++ b/_posts/2014-09-05-we-open-sourced-our-isomorphic-javascript-website.markdown
@@ -17,7 +17,7 @@ Over the past few months, we've rewritten our web front-end to move off Rails an
## Isomorphic vs Monolithic
-Our transition to an isomorphic Javascript stack has been very successful albeit with some speed bumps. If you're interested in the details we've written [a blog post](http://artsy.github.io/blog/2013/11/30/rendering-on-the-server-and-client-in-node-dot-js/), given a talk at [Node on the Road](https://www.joyent.com/developers/videos/node-js-on-the-road-nyc-craig-spaeth-brennan-moore) (slides [here](http://www.slideshare.net/craigspaeth/artsy-node-on-the-roady-slides)), and another more extensive talk at [this meetup](http://www.hakkalabs.co/articles/monolithic-to-distributed-how-artsy-transitioned-from-ruby-on-rails-to-node-js-and-isomorphic-javascript#).
+Our transition to an isomorphic Javascript stack has been very successful albeit with some speed bumps. If you're interested in the details we've written [a blog post](https://artsy.github.io/blog/2013/11/30/rendering-on-the-server-and-client-in-node-dot-js/), given a talk at [Node on the Road](https://www.joyent.com/developers/videos/node-js-on-the-road-nyc-craig-spaeth-brennan-moore) (slides [here](http://www.slideshare.net/craigspaeth/artsy-node-on-the-roady-slides)), and another more extensive talk at [this meetup](http://www.hakkalabs.co/articles/monolithic-to-distributed-how-artsy-transitioned-from-ruby-on-rails-to-node-js-and-isomorphic-javascript#).
The short story is that we moved from a monolithic rails app to a couple of Node servers on Heroku. This vastly improved the performance of our site and our own development speed. Using the patterns in Ezel, we are able to tailor assets packages to specific pages and render some of the page on the server. This cut our page-load in half (from 6.5 seconds to under 3 seconds) and our tests take about 5 minutes (down from around 5 hours!) with little reduction in coverage. Performance numbers aside, our real win was dramatically improved development speed due to some architecture decisions we made.
diff --git a/_posts/2014-11-13-eidolon-retrospective.markdown b/_posts/2014-11-13-eidolon-retrospective.markdown
index 0dc0096938..887aa15ca6 100644
--- a/_posts/2014-11-13-eidolon-retrospective.markdown
+++ b/_posts/2014-11-13-eidolon-retrospective.markdown
@@ -76,7 +76,7 @@ A component that I had not developed before was an admin panel that Orta made. T
Speaking of production and staging, to prevent developers from accidentally placing bids on production and to prevent live users from inadvertently using the staging servers, Orta made a simple badge that would let you know if you were on staging. If you were running in the simulator, it would also alert you if you were running on production. This was great, but wouldn’t prevent someone from accidentally placing bids on the production server while testing on a device. [Our solution](https://github.com/artsy/eidolon/blob/9181be833459307bb749df2264b3d339b371ee59/Kiosk/Auction%20Listings/ListingsViewController.swift#L157-L169) was to check your current wifi network name. If it looks like you’re at the Artsy offices, then the production flag is shown, even on a device.
-So we’ve got the scaffolding for a great app and it was time to really begin development. Using ReactiveCocoa, we were able to make our [XApp authentication transparent](http://artsy.github.io/blog/2014/09/22/transparent-prerequisite-network-requests/). Functional reactive programming had other great benefits, like [scheduling automated refreshes](https://github.com/artsy/eidolon/blob/9181be833459307bb749df2264b3d339b371ee59/Kiosk/Auction%20Listings/ListingsViewController.swift#L87-L137) of auction listings. We may have [gone overboard](https://github.com/artsy/eidolon/blob/9181be833459307bb749df2264b3d339b371ee59/Kiosk/Auction%20Listings/ListingsViewController.swift#L48-L68) in one instance (cleaning that up is on my todo list), but ReactiveCocoa has made modelling complex behaviour of Eidolon relatively easy.
+So we’ve got the scaffolding for a great app and it was time to really begin development. Using ReactiveCocoa, we were able to make our [XApp authentication transparent](https://artsy.github.io/blog/2014/09/22/transparent-prerequisite-network-requests/). Functional reactive programming had other great benefits, like [scheduling automated refreshes](https://github.com/artsy/eidolon/blob/9181be833459307bb749df2264b3d339b371ee59/Kiosk/Auction%20Listings/ListingsViewController.swift#L87-L137) of auction listings. We may have [gone overboard](https://github.com/artsy/eidolon/blob/9181be833459307bb749df2264b3d339b371ee59/Kiosk/Auction%20Listings/ListingsViewController.swift#L48-L68) in one instance (cleaning that up is on my todo list), but ReactiveCocoa has made modelling complex behaviour of Eidolon relatively easy.
Of course, learning how to ReactiveCocoa is no easy feat. At this point, Orta and Laura were both working on Eidolon. There were many conversations in our Slack chatroom about how to approach problem-solving the ReactiveCocoa way and, with some time, they both became proficient at creating and manipulating signals. Sweet.
diff --git a/_posts/2014-11-18-debugging-our-hardware-problem.markdown b/_posts/2014-11-18-debugging-our-hardware-problem.markdown
index 5b06a29271..eecb3bafe0 100644
--- a/_posts/2014-11-18-debugging-our-hardware-problem.markdown
+++ b/_posts/2014-11-18-debugging-our-hardware-problem.markdown
@@ -7,7 +7,7 @@ categories: [iOS, mobile]
author: ash
---
-For the past few months, Artsy’s mobile team has been working on [Eidolon](https://github.com/artsy/eidolon), a bidding kiosk for Artsy’s auctions platform. While we’ve written a [retrospective](http://artsy.github.io/blog/2014/11/13/eidolon-retrospective/) on the process of making Eidolon from the software side of things, we didn’t really touch on how our software is being used.
+For the past few months, Artsy’s mobile team has been working on [Eidolon](https://github.com/artsy/eidolon), a bidding kiosk for Artsy’s auctions platform. While we’ve written a [retrospective](https://artsy.github.io/blog/2014/11/13/eidolon-retrospective/) on the process of making Eidolon from the software side of things, we didn’t really touch on how our software is being used.
diff --git a/_posts/2015-01-04-cocoapods-and-frameworks.markdown b/_posts/2015-01-04-cocoapods-and-frameworks.markdown
index bac02c5b27..4688def71a 100644
--- a/_posts/2015-01-04-cocoapods-and-frameworks.markdown
+++ b/_posts/2015-01-04-cocoapods-and-frameworks.markdown
@@ -21,7 +21,7 @@ The final step to update was getting our tests to pass. Up to this point, we had
-Eidolon is pretty distinct among iOS applications: from day one, it was developed completely in the open. Developing this kind of app in the open posed some new challenges, including limiting access to fonts for which we have licenses to use but not to distribute. Orta [solved this problem](http://artsy.github.io/blog/2014/06/20/artsys-first-closed-source-pod/) earlier this year by having two pods: one private, and one public, but with identical header files. When installing the dependencies, CocoaPods uses one pod or the other depending on a [complex heuristic](https://github.com/artsy/eidolon/blob/4ae52f166f2d1620f25a59f36e6a87915ba32705/Podfile#L31-L35). However, the names of the pods are used as names for the Swift modules generated from them. Since the pods have different names, the `import Artsy_UIFonts` statements won't make sense if someone only has access to the `Artsy_OSSUIFonts` module. Swift's lack of a preprocessor led to some [hacks](https://github.com/artsy/eidolon/commit/57aa66681727cfed11239f9b5a62bb59fee35f1a). However, CocoaPods now allows you to specify a module name for a pod, so we'll be fixing the issue [shortly](https://github.com/artsy/Artsy-OSSUIFonts/issues/1).
+Eidolon is pretty distinct among iOS applications: from day one, it was developed completely in the open. Developing this kind of app in the open posed some new challenges, including limiting access to fonts for which we have licenses to use but not to distribute. Orta [solved this problem](https://artsy.github.io/blog/2014/06/20/artsys-first-closed-source-pod/) earlier this year by having two pods: one private, and one public, but with identical header files. When installing the dependencies, CocoaPods uses one pod or the other depending on a [complex heuristic](https://github.com/artsy/eidolon/blob/4ae52f166f2d1620f25a59f36e6a87915ba32705/Podfile#L31-L35). However, the names of the pods are used as names for the Swift modules generated from them. Since the pods have different names, the `import Artsy_UIFonts` statements won't make sense if someone only has access to the `Artsy_OSSUIFonts` module. Swift's lack of a preprocessor led to some [hacks](https://github.com/artsy/eidolon/commit/57aa66681727cfed11239f9b5a62bb59fee35f1a). However, CocoaPods now allows you to specify a module name for a pod, so we'll be fixing the issue [shortly](https://github.com/artsy/Artsy-OSSUIFonts/issues/1).
Of course, Swift still has some rough edges, too. Namely, we can't compile our app with compiler optimizations enabled – the compiler will segfault. It turns out that one of our dependencies was causing the segfault – probably just a Swift compiler bug, but we needed a workaround until it's fixed. I got more familiar with post-install hooks when I dipped my toes into Ruby to [disable the optimization on specific pods](https://github.com/ashfurrow/cocoapods-chillax-swift).
diff --git a/_posts/2015-03-31-the-culture-of-openness-artsy-mobile.markdown b/_posts/2015-03-31-the-culture-of-openness-artsy-mobile.markdown
index 3e75bbe46b..8be33a3c7d 100644
--- a/_posts/2015-03-31-the-culture-of-openness-artsy-mobile.markdown
+++ b/_posts/2015-03-31-the-culture-of-openness-artsy-mobile.markdown
@@ -7,9 +7,24 @@ categories: [mobile, Open-Source]
author: [sarahscott, laura]
---
-Recently, the Artsy Mobile team had the pleasure of working together on [an article](http://www.objc.io/issue-22/artsy.html) for [objc.io](http://www.objc.io), an online publication dedicated to in-depth articles about iOS and OS X development. Each monthly issue consists of several articles centered around a theme—past issues include [Testing](http://www.objc.io/issue-15/), [Animations](http://www.objc.io/issue-12/) and [Swift](http://www.objc.io/issue-16/). objc.io’s latest issue, [iOS at Scale](http://www.objc.io/issue-22), features articles by a handful of developers about how they approach iOS development at their respective companies. Our contribution to the issue is a collaboratively-written article by and about Artsy’s Mobile team from the angle of Artsy's focus on the core value of openness that is foundational to how we (and the greater Artsy team) work.
+Recently, the Artsy Mobile team had the pleasure of working together on
+[an article](https://www.objc.io/issue-22/artsy.html) for [objc.io](https://www.objc.io), an online publication
+dedicated to in-depth articles about iOS and OS X development. Each monthly issue consists of several articles
+centered around a theme—past issues include [Testing](https://www.objc.io/issue-15/),
+[Animations](https://www.objc.io/issue-12/) and [Swift](https://www.objc.io/issue-16/). objc.io’s latest issue,
+[iOS at Scale](https://www.objc.io/issue-22), features articles by a handful of developers about how they approach
+iOS development at their respective companies. Our contribution to the issue is a collaboratively-written article
+by and about Artsy’s Mobile team from the angle of Artsy's focus on the core value of openness that is foundational
+to how we (and the greater Artsy team) work.
As our article puts it:
-> Our team intrinsically believes in the ideas of open source. Though our individual motivations vary — from a conviction in the power of education to a determination to help others see from giants’ shoulders — we all maintain the value of open source.
-iOS at Artsy is characterized by a culture of open source stewardship. Although our team is small, our contributions to the Cocoa developer community are significant. We hope our article sheds some light on our development and testing practices while also providing a high-level look into our team’s philosophy. If you’d like to learn more, feel free to reach out to us at diff --git a/_posts/2018-05-01-JavaScriptures-1-React.markdown b/_posts/2018-05-01-JavaScriptures-1-React.markdown index e3ef38ea57..d7f0e178d3 100644 --- a/_posts/2018-05-01-JavaScriptures-1-React.markdown +++ b/_posts/2018-05-01-JavaScriptures-1-React.markdown @@ -27,7 +27,7 @@ myself. Slides on Speakerdeck
-[omakase]: http://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ +[omakase]: https://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ [luc]: https://twitter.com/lucsucces [recording]: https://youtu.be/k_f7Ff7bREc [slides]: https://speakerdeck.com/artsyopensource/javascriptures-1-react diff --git a/_posts/2018-05-02-JavaScriptures-2-TypeScript.markdown b/_posts/2018-05-02-JavaScriptures-2-TypeScript.markdown index f370819c54..1e328c54c8 100644 --- a/_posts/2018-05-02-JavaScriptures-2-TypeScript.markdown +++ b/_posts/2018-05-02-JavaScriptures-2-TypeScript.markdown @@ -24,7 +24,7 @@ inference, generics and how they all come together in your tools. Slides on Speakerdeck -[omakase]: http://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ +[omakase]: https://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ [luc]: https://twitter.com/lucsucces [recording]: https://youtu.be/KXPZvjCUlAA [slides]: https://speakerdeck.com/artsyopensource/javascriptures-2-typescript diff --git a/_posts/2018-05-04-JavaScriptures-3-Styled-Components.markdown b/_posts/2018-05-04-JavaScriptures-3-Styled-Components.markdown index d3370afe99..7b046bd0d0 100644 --- a/_posts/2018-05-04-JavaScriptures-3-Styled-Components.markdown +++ b/_posts/2018-05-04-JavaScriptures-3-Styled-Components.markdown @@ -21,7 +21,7 @@ have Anandaroop Roy and Jon Allured covering all the details. Slides on Speakerdeck -[omakase]: http://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ +[omakase]: https://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ [luc]: https://twitter.com/lucsucces [recording]: https://youtu.be/K7xafqfcC-4 [slides]: https://speakerdeck.com/artsyopensource/javascriptures-3-styled-components diff --git a/_posts/2018-06-02-Announcing-Artsy-x-React-Native.markdown b/_posts/2018-06-02-Announcing-Artsy-x-React-Native.markdown index a551a41324..26f2a81195 100644 --- a/_posts/2018-06-02-Announcing-Artsy-x-React-Native.markdown +++ b/_posts/2018-06-02-Announcing-Artsy-x-React-Native.markdown @@ -23,8 +23,8 @@ tooling up for success, and create solid animations. We want [Artsy x React-Native][axrn] to be about getting you up to speed with the framework, so you can make your own decisions going forward. -[documented]: http://artsy.github.io/search/?q=react+native -[our]: http://artsy.github.io/series/react-native-at-artsy/ -[journey]: http://artsy.github.io/blog/2016/08/15/React-Native-at-Artsy/ -[reasoning]: http://artsy.github.io/blog/2018/03/17/two-years-of-react-native/ +[documented]: https://artsy.github.io/search/?q=react+native +[our]: https://artsy.github.io/series/react-native-at-artsy/ +[journey]: https://artsy.github.io/blog/2016/08/15/React-Native-at-Artsy/ +[reasoning]: https://artsy.github.io/blog/2018/03/17/two-years-of-react-native/ [axrn]: https://www.artsy.net/x-react-native diff --git a/_posts/2018-06-13-JavaScriptures-4.1-Relay.markdown b/_posts/2018-06-13-JavaScriptures-4.1-Relay.markdown index de95df43a6..e0a81bd091 100644 --- a/_posts/2018-06-13-JavaScriptures-4.1-Relay.markdown +++ b/_posts/2018-06-13-JavaScriptures-4.1-Relay.markdown @@ -24,7 +24,7 @@ with all of the Artsy tooling. Slides on Speakerdeck -[omakase]: http://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ +[omakase]: https://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ [alloy]: https://twitter.com/alloy [recording]: https://youtu.be/-Ax46yDG7oc [slides]: https://speakerdeck.com/artsyopensource/javascriptures-4-dot-1-relay? diff --git a/_posts/2018-06-14-JavaScriptures-4.2-Local-State.markdown b/_posts/2018-06-14-JavaScriptures-4.2-Local-State.markdown index b218f4d84e..226d5798a4 100644 --- a/_posts/2018-06-14-JavaScriptures-4.2-Local-State.markdown +++ b/_posts/2018-06-14-JavaScriptures-4.2-Local-State.markdown @@ -24,7 +24,7 @@ interacting with local state in our different applications. Slides on Speakerdeck -[omakase]: http://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ +[omakase]: https://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ [chris]: https://github.com/damassi [recording]: https://youtu.be/uLeZnpvVpxA [slides]: https://speakerdeck.com/artsyopensource/javascriptures-4-dot-2-local-state?slide=1 diff --git a/_posts/2018-06-15-JavaScriptures-5-Babel-Webpack.markdown b/_posts/2018-06-15-JavaScriptures-5-Babel-Webpack.markdown index 3c3cdcbf7d..56fb38445f 100644 --- a/_posts/2018-06-15-JavaScriptures-5-Babel-Webpack.markdown +++ b/_posts/2018-06-15-JavaScriptures-5-Babel-Webpack.markdown @@ -21,7 +21,7 @@ and Babel in a fresh application. Slides on Speakerdeck -[omakase]: http://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ +[omakase]: https://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ [chris]: https://github.com/damassi [recording]: https://youtu.be/NhYot0NC6q8 [slides]: https://speakerdeck.com/artsyopensource/javascriptures-5-babel-and-webpack?slide=1 diff --git a/_posts/2018-08-10-On-Context-Switching.markdown b/_posts/2018-08-10-On-Context-Switching.markdown index fe0f2886c3..62a7ce9e97 100644 --- a/_posts/2018-08-10-On-Context-Switching.markdown +++ b/_posts/2018-08-10-On-Context-Switching.markdown @@ -213,12 +213,12 @@ Do you have any useful ideas for speeding up context switching? I'm open to impr [active]: https://gist.github.com/paulmillr/2657075 [flow]: https://en.wikipedia.org/wiki/Flow_(psychology) -[ossd]: http://artsy.github.io/series/open-source-by-default/ +[ossd]: https://artsy.github.io/series/open-source-by-default/ [hiring]: https://www.artsy.net/jobs#engineering [exp]: https://github.com/orta/cocoapods-fix-react-native#contributing-back [vision]: https://github.com/danger/danger-js/blob/master/VISION.md#danger-for-js [rdd]: https://tom.preston-werner.com/2010/08/23/readme-driven-development.html -[chris]: http://artsy.github.io/author/chris/ +[chris]: https://artsy.github.io/author/chris/ [consign]: https://github.com/artsy/emission/tree/master/src/lib/Components/Consignments [prettier]: https://prettier.io [danger]: https://danger.systems @@ -226,7 +226,7 @@ Do you have any useful ideas for speeding up context switching? I'm open to impr [lint-staged]: https://github.com/okonet/lint-staged [danger-local]: http://danger.systems/js/tutorials/fast-feedback.html [oma]: https://www.youtube.com/watch?v=1Z3loALSVQM -[sherlock]: http://artsy.github.io/blog/2017/02/05/Retrospective-Swift-at-Artsy/#Developer.Experience +[sherlock]: https://artsy.github.io/blog/2017/02/05/Retrospective-Swift-at-Artsy/#Developer.Experience [hig]: https://developer.apple.com/design/human-interface-guidelines/macos/overview/themes/ [gs]: https://github.com/kamranahmedse/git-standup [tweet]: https://twitter.com/orta/status/1028764128310185984 diff --git a/_posts/2018-08-22-engineering-guiding-principles.markdown b/_posts/2018-08-22-engineering-guiding-principles.markdown index baa4afe70d..93f51d1fee 100644 --- a/_posts/2018-08-22-engineering-guiding-principles.markdown +++ b/_posts/2018-08-22-engineering-guiding-principles.markdown @@ -82,7 +82,7 @@ Remember that earlier example of openness-vs-quality? That is answered explicitl [pr]: https://github.com/artsy/meta/pull/41 [company_values]: https://www.artsy.net/article/carter-cleveland-why-define-company-values [values]: https://github.com/artsy/README/blob/master/culture/what-is-artsy.md#artsy-values -[obd]: http://artsy.github.io/series/open-source-by-default/ +[obd]: https://artsy.github.io/series/open-source-by-default/ [objcio]: https://www.objc.io/issues/22-scale/artsy/ [principles]: https://github.com/artsy/README/blob/master/culture/engineering-principles.md [gh]: https://github.com/artsy diff --git a/_posts/2018-10-04-artsy-frontend-history.markdown b/_posts/2018-10-04-artsy-frontend-history.markdown index 6ade4e8693..09df496011 100644 --- a/_posts/2018-10-04-artsy-frontend-history.markdown +++ b/_posts/2018-10-04-artsy-frontend-history.markdown @@ -175,14 +175,14 @@ coming next, and I can't wait to share it with you. Have a great day! [node]: https://github.com/ruby-grape/grape [bem]: http://getbem.com/introduction/ [ezel]: https://github.com/artsy/ezel -[2013_review]: http://artsy.github.io/blog/2013/11/30/rendering-on-the-server-and-client-in-node-dot-js/ -[2017_review]: http://artsy.github.io/blog/2017/04/14/artsy-technology-stack-2017/ -[auctions]: http://artsy.github.io/blog/2016/08/09/the-tech-behind-live-auction-integration/ +[2013_review]: https://artsy.github.io/blog/2013/11/30/rendering-on-the-server-and-client-in-node-dot-js/ +[2017_review]: https://artsy.github.io/blog/2017/04/14/artsy-technology-stack-2017/ +[auctions]: https://artsy.github.io/blog/2016/08/09/the-tech-behind-live-auction-integration/ [stitch]: https://github.com/artsy/stitch -[force_modern]: http://artsy.github.io/blog/2017/09/05/Modernizing-Force/ +[force_modern]: https://artsy.github.io/blog/2017/09/05/Modernizing-Force/ [typescript]: http://www.typescriptlang.org [flow]: https://flow.org -[fe_js]: http://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ +[fe_js]: https://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ [rclt]: https://github.com/relay-tools/relay-compiler-language-typescript [reaction]: https://github.com/artsy/reaction [styled-components]: https://www.styled-components.com @@ -192,9 +192,9 @@ coming next, and I can't wait to share it with you. Have a great day! [graphql]: https://graphql.org [moya]: https://ashfurrow.com/blog/the-spirit-of-moya/ [metaphysics]: https://github.com/artsy/metaphysics/ -[relay_post]: http://artsy.github.io/blog/2018/07/25/Relay-Networking-Deep-Dive/ +[relay_post]: https://artsy.github.io/blog/2018/07/25/Relay-Networking-Deep-Dive/ [hokusai]: https://github.com/artsy/hokusai [ts_inc]: https://artsy.github.io/blog/2017/11/27/Babel-7-and-TypeScript/ -[helix]: http://artsy.github.io/blog/2015/04/08/creating-a-dynamic-single-page-app-for-our-genome-team-using-react/ +[helix]: https://artsy.github.io/blog/2015/04/08/creating-a-dynamic-single-page-app-for-our-genome-team-using-react/ [positron]: https://github.com/artsy/positron -[javascriptures]: http://artsy.github.io/series/javascriptures/ +[javascriptures]: https://artsy.github.io/series/javascriptures/ diff --git a/_posts/2018-11-28-artsy-auth.md b/_posts/2018-11-28-artsy-auth.md index 3e6bd2aecf..af4af10104 100644 --- a/_posts/2018-11-28-artsy-auth.md +++ b/_posts/2018-11-28-artsy-auth.md @@ -150,7 +150,7 @@ Again, to reiterate: a JWT is not encrypted. It's publicly readable. Do not put JWTs. If you'd like to learn more about how Artsy thinks about and uses JWTs you can read -[this blog post](http://artsy.github.io/blog/2016/10/26/jwt-artsy-journey/) +[this blog post](https://artsy.github.io/blog/2016/10/26/jwt-artsy-journey/) ### Generating Secret Keys diff --git a/_posts/2018-12-11-GraphQL-Stitching.markdown b/_posts/2018-12-11-GraphQL-Stitching.markdown index 9c5f0d5a39..d8544916cc 100644 --- a/_posts/2018-12-11-GraphQL-Stitching.markdown +++ b/_posts/2018-12-11-GraphQL-Stitching.markdown @@ -363,7 +363,7 @@ Future?][igtf] for a more philosophical take also.) [stitching_announcement]: https://dev-blog.apollodata.com/the-next-generation-of-schema-stitching-2716b3b259c0 [stitching_out]: https://dev-blog.apollodata.com/graphql-tools-2-0-with-schema-stitching-8944064904a5 -[monolith]: http://artsy.github.io/blog/2017/04/14/artsy-technology-stack-2017/#Artsy.Technology.Infrastructure.2017.-.Splitting.the.Monolith +[monolith]: https://artsy.github.io/blog/2017/04/14/artsy-technology-stack-2017/#Artsy.Technology.Infrastructure.2017.-.Splitting.the.Monolith [mp]: https://github.com/artsy/metaphysics/ [stitch_mp]: https://github.com/artsy/metaphysics/tree/1423ee39f8e348805710080a4857e6575d3ddade/src/lib/stitching [apollo-http-link]: https://www.apollographql.com/docs/link/links/http.html @@ -377,7 +377,7 @@ Future?][igtf] for a more philosophical take also.) [sdl]: https://blog.graph.cool/graphql-sdl-schema-definition-language-6755bcb9ce51 [init]: https://github.com/artsy/metaphysics/commit/50b23f1738b9fa9757ff83c2d1e0d265c70e4e90 [mn]: https://www.freiksenet.com -[igtf]: http://artsy.github.io/blog/2018/05/08/is-graphql-the-future/ +[igtf]: https://artsy.github.io/blog/2018/05/08/is-graphql-the-future/ [high]: https://github.com/artsy/README/blob/master/culture/highlights.md#highlights [ex]: https://github.com/artsy/metaphysics/pull/809 [rev]: https://github.com/artsy/README/blob/master/culture/engineering-principles.md#incremental-revolution diff --git a/_posts/2019-01-08-automation-encourages-more-automation.markdown b/_posts/2019-01-08-automation-encourages-more-automation.markdown index 6c3b8f807f..556bf03de0 100644 --- a/_posts/2019-01-08-automation-encourages-more-automation.markdown +++ b/_posts/2019-01-08-automation-encourages-more-automation.markdown @@ -91,13 +91,13 @@ it was very satisfying. I would say that's _definitely_ worth it. -[automate]: http://artsy.github.io/blog/2018/05/07/fully-automated-standups/ +[automate]: https://artsy.github.io/blog/2018/05/07/fully-automated-standups/ [spof]: https://en.wikipedia.org/wiki/Single_point_of_failure -[support]: http://artsy.github.io/blog/2018/05/25/support-process/ +[support]: https://artsy.github.io/blog/2018/05/25/support-process/ [docs]: https://github.com/artsy/README/blob/eb2f23c835983223877a6031475153db93e98e8c/events/open-standup.md [xkcd]: https://xkcd.com/1319/ [pr]: https://github.com/artsy/peril-settings/pull/87 -[peril]: http://artsy.github.io/blog/2017/09/04/Introducing-Peril/ +[peril]: https://artsy.github.io/blog/2017/09/04/Introducing-Peril/ [gsa]: https://cloud.google.com/iam/docs/understanding-service-accounts [slack]: https://github.com/slackapi/node-slack-sdk#features [peril_installation]: https://github.com/artsy/peril-settings diff --git a/_posts/2019-01-30-why-we-run-our-blog.md b/_posts/2019-01-30-why-we-run-our-blog.md index 5e9a5d043c..dab0dfa558 100644 --- a/_posts/2019-01-30-why-we-run-our-blog.md +++ b/_posts/2019-01-30-why-we-run-our-blog.md @@ -222,7 +222,7 @@ All three of these you can set up automatic hosting from GitHub in about 10-15m. [dev]: https://write.as/blog/ending-our-medium-integration [search]: https://github.com/artsy/artsy.github.io/pull/332 [peril]: https://github.com/artsy/README/blob/master/culture/peril.md -[int]: http://artsy.github.io/blog/2019/01/23/artsy-engineering-hiring/ +[int]: https://artsy.github.io/blog/2019/01/23/artsy-engineering-hiring/ [publishers]: http://www.niemanlab.org/2018/05/medium-abruptly-cancels-the-membership-programs-of-its-21-remaining-publisher-partners/ diff --git a/_posts/2019-03-01-custom-editorial-features.markdown b/_posts/2019-03-01-custom-editorial-features.markdown index f2118107c0..09064e4456 100644 --- a/_posts/2019-03-01-custom-editorial-features.markdown +++ b/_posts/2019-03-01-custom-editorial-features.markdown @@ -81,7 +81,7 @@ Published examples of custom articles that use curations are: - [Inside the Biennale](https://www.artsy.net/venice-biennale) - [The Year in Art 2016](https://www.artsy.net/2016-year-in-art) -_See [previous blog post](http://artsy.github.io/blog/2017/02/01/year-in-art/) on creating The Year in Art 2016._ +_See [previous blog post](https://artsy.github.io/blog/2017/02/01/year-in-art/) on creating The Year in Art 2016._ **SuperArticles:** diff --git a/_posts/2019-03-12-so-you-want-to-be-an-engineer.md b/_posts/2019-03-12-so-you-want-to-be-an-engineer.md index ef922a8c95..347ab2dac1 100644 --- a/_posts/2019-03-12-so-you-want-to-be-an-engineer.md +++ b/_posts/2019-03-12-so-you-want-to-be-an-engineer.md @@ -14,7 +14,7 @@ two years at that point, first as a marketing intern working on SEO and then as email) team. I'd consistently been working on small technical projects; first doing [some work](https://github.com/artsy/positron/commit/3176282a3ea94c626e9d851b7c0dd27a1bb0fcb4) on a tool for SEO optimization for our Editorial team, then building -[emails with MJML](http://artsy.github.io/blog/2018/11/19/mjml/), and a few other bits and bobs. But I didn't think +[emails with MJML](https://artsy.github.io/blog/2018/11/19/mjml/), and a few other bits and bobs. But I didn't think of it as a serious pursuit. Mostly, that was due to my experience programming in the past—I did about half a CS major in undergrad. At the @@ -159,7 +159,7 @@ transitioning from one team at Artsy to another (Marketing → Engineering), I b of Artsy's goals and needs, which helps with day-to-day prioritization. And when I'm in a sprint planning meeting or a product review and someone has a question about email or marketing, I can often answer—or at least I know who to talk to to get to the bottom of the issue quickly. Plus if at some point my team needs to code emails, my -[past experience](http://artsy.github.io/blog/2018/11/19/mjml/) will come in very handy. +[past experience](https://artsy.github.io/blog/2018/11/19/mjml/) will come in very handy. There are also life experiences that serve me well on the Engineering team. My work as a server and bartender made me good at clear communication with stakeholders. Cooking for big groups of friends has made me better at diff --git a/artsy-x-react-native.html b/artsy-x-react-native.html index 0ca3e63754..ae85d1c1fe 100644 --- a/artsy-x-react-native.html +++ b/artsy-x-react-native.html @@ -439,7 +439,7 @@