The Gilt technology organization. We make work.

Gilt Tech

December Meetups at HBC Digital

John Coghlan continuous integration

We’re closing out 2016 with two more meetups at our offices in Brookfied Place.

New York Scala University - December 13

On Tuesday, December 13 at 6:30pm, Puneet Arya, Senior Application Developer at HBC Digital, will talk about how MongoDB and the Play Framework get along.

The talk will touch on: * What is MongoDB and how it can be used. * How MongoDB works with Play Framework. * What configuration is needed to make Mongo DB work with Play. * Explore CRUD operations for MongoDB with Scala and Play Framework.

Please RSVP here if you’d like to attend.

HBC Digital Technology Meetup - December 15

We’re partnering with the NYC PostgreSQL User Group on Thursday, December 15 at 6:30pm to host Bruce Momjian.

Here’s the description of Bruce’s talk:

Postgres 9.6 adds many features that take the database to a new level of scalability, with parallelism and multi-CPU-socket scaling improvements.

Easier maintenance is achieved by reduced cleanup overhead and adding snapshot and idle-transaction controls. Enhanced monitoring simplifies the job of administrators. Foreign data wrapper and full text improvements are also included in this release. The talk will also cover some of the major focuses of the next major release, Postgres 10.

Speaker: Bruce Momjian is co-founder and core team member of the PostgreSQL Global Development Group, and has worked on PostgreSQL since 1996. He has been employed by EnterpriseDB since 2006. He has spoken at many international open-source conferences and is the author of PostgreSQL: Introduction and Concepts, published by Addison-Wesley. Prior to his involvement with PostgreSQL, Bruce worked as a consultant, developing custom database applications for some of the world’s largest law firms.

As an academic, Bruce holds a Masters in Education, was a high school computer science teacher, and lectures internationally at universities.

Please RSVP here if you’d like to attend.

meetups 33 scala 14 postgresql 2
Gilt Tech

Increasing Build IQ with Travis CI

Andrew Powell continuous integration

Continuous Integration is a must these days. And for social, open source projects it’s crucial. Our tool of choice for automated testing is Travis CI. Like most tools, Travis does what it does well. Unfortunately it’s not very “smart”. Heaven help you if you have a large or modular project with a multitude of tests - you’ll be waiting an eternity between builds.

And that’s exactly what we ran into. We have a repository that contains 30 NPM modules, each with their own specs (tests). These modules are part of an aging assets pipeline that I briefly mentioned last week. As such each module is subject to a litany of tasks each time a change is made. Travis CI is hooked into the repo and for each Pull Request would run specs for every module, assuring that there are no errors in the code changes contained in the PR. When you’re only working on one or two modules the run-time for the tasks is relatively low; typically 1 - 2 minutes. That of course depends on things such as npm install time, as each module requires an install for testing. Multiply that by 30 and you start to see where the problem arises.

Waiting Sucks

Without targeted build testing we’re left waiting or task-shifting until the build completes successfully. Our need was clear: figure out what files were affected, map and filter the results, and run only the specs for the modules changed in any particular Pull Request or push. That’s where travis-target comes into play.

Here’s a snippet of our repo structure, for reference:


Target Acquired

In order to target modules, we need to know what their normalized names are; the names that we publish them to NPM under. Because of some legacy stuff baked into our pipeline, we store modules at group/name but publish them as So let’s fire up travis-target (bear in mind we’re using ES6 syntax that Node v7 supports).

const target = require('travis-target');
const pattern = /^src\//;

let targets = await target();

Let’s pretend that the common.event_registry and tracking.cart modules were both modified in one Pull Request (a common pattern for us) - our results would could look like this:


But that’s just silly, so let’s give travis-target some options to work with:

const target = require('travis-target');
const pattern = /^src\//;

let targets = await target({
  pattern: pattern,
  map: (result) => {
    let parts;

    result = result.replace(pattern, '');
    parts = result.split('/');

    return parts.slice(0, 2).join('.');

By passing pattern in options, we’re telling travis-target to filter on (or return only those results which match) the regular expression pattern. That gives us an initial result set of directories starting with src/.


You’ll notice that the initial example of results contained some duplicate directories; travis-target cleans that up for you.

Next, we specify the map function on options. That’ll let us transform the each element in the Array of results so that it’s ready to use. Our results would now look like this:


Great Justice

Using this last result set, we now know which modules were affected in the PR, and we know which modules to run specs for. Our next steps are firing off a sequence of shell commands using @exponent/spawn-async, which plays nicely with async/await patterns now supported in Node v7.1 with the --harmony-async-await flag.

Since we implemented this pattern, build times for our PRs are in the 1-2 minute range; a vast improvement and one sure to bring developer happiness in some small degree.


Originally published at on November 16, 2016.

continuous integration 2 node.js 4 open source 64 travis ci 1
Gilt Tech

Linting NPM Version Conflicts

Andrew Powell node

Say you had the need for shared front-end assets (scripts, stylesheets, images, etc.) and a need for an entire org to access them, independently, for reliable builds of many different apps which used those assets. NPM might be a good choice - With NPM’s move to a flat-ish install tree, it’s still a relevant choice. But what about package version conflicts?

At Gilt, the choice was made years ago; before Bower, JSPM, and the host of other package managers came to be. NPM was the logical choice then. And we’re still using it.


Traditionally hard. With the nested NPM installs of yesteryear it was compounded. Not only did we have to detect and move around scripts and other assets from within module packages, we also had to check versions against one another. That was essential in building the final script bundles and combining css for a production deployment.

The Scenario

Let’s say that fictitious module-a depends on module-b and module-util. And that module-b also depends on module-util. That’s a pretty straightforward tree and the bundle for the scripts of that tree should be easy. You’d think. But consider that scenario if module-a depends on module-util@1.0.0 and module-b depends on module-util@0.5.0. Now we’ve got a conflict, and that could totally hose our production bundle.

The Trees

In prior versions of NPM, the npm install tree would look like this:


In today’s NPM it looks like this:


NPM is quarantining outlier versions of shared modules so that everything plays nicely in a Node.js environment. That’s cool for Node, but not for us… using this as a front-end assets package manager.

A Solution?

What we ended up doing was installing the entire package tree to a temporary directory, and then polling every package.json in that directory, building a dependency tree and looking through the tree for conflicts. It worked. It wasn’t a bad method, and it’s one that we duplicated in three generations of tooling.

A Better Solution

That’s a heck of a lot of work to perform after we make NPM do a heck of a lot of work. There’s a better, faster way. Using NPM’s ability to pull metadata quickly for modules, we can leverage Node 7’s async/await capabilities to produce some elegant code that quickly retrieves and maps an NPM module’s version dependency tree.

Running that script for koa, we get:

koa: [ { version: '1.2.4', parent: '' } ],
  'koa-compose': [ { version: '2.5.1', parent: 'koa' } ],
  'koa-is-json': [ { version: '1.0.0', parent: 'koa' } ],
  'media-typer': [ { version: '0.3.0', parent: 'type-is' } ],
   [ { version: '1.24.0', parent: 'mime-types' },
     { version: '1.24.0', parent: 'mime-types' },
     { version: '1.24.0', parent: 'mime-types' } ],

In which we can clearly see that there are no version conflicts. That’s a snippet of the much larger tree returned, but the result is the same. Running that script on our fictitious module-a, the result would look like:

  'module-b': [ { version: '0.0.1', parent: 'module-a' } ]
  'module-util': [
    { version: '1.0.0', parent: 'module-a' },
    { version: '0.5.0', parent: 'module-b' },

And our conflict is visible.


While interesting, this isn’t inherently useful by itself. Moving forward, we’ll be wrapping this into a Gulp plugin with proper reporting output and blocking, and run from the local package.json file.


Originally published at on November 9, 2016.

npm 4 node.js 4 open source 64
Gilt Tech

Running with Scissors: Koa2 and Vue.js

Andrew Powell node

We love Koa at Gilt. (Hell, I love Koa.) Embarking on a new project, I wanted to try something that wasn’t React or Angular. After poking at the alternatives I landed on Vue.js. I picked up the sharpest pair of scissors I could find and started running.

The Chosen Tech

If you haven’t heard of Koa:

Koa is a new web framework designed by the team behind Express, which aims to be a smaller, more expressive, and more robust foundation for web applications and APIs.

Koa is Express without the bells and whistles from the factory. Koa is the stock car that you bolt aftermarket parts onto, based on your needs. It’s fast as hell. It’s small. It’s a dang joy to work with. Koa2 improves on performance and makes use of await/async patterns.

If you haven’t heard of Vue.js;

Vue is a progressive framework for building user interfaces. …Vue is designed from the ground up to be incrementally adoptable. …is focused on the view layer only, and is also perfectly capable of powering sophisticated Single-Page Applications.

Basically Vue.js takes the good parts from React, Angular, and Aurelia and bundles them into a single lib. Who want’s to go fast?. React folks won’t like it because there’s no JSX and there’s two-way binding. I dig it explicitly because I personally think JSX is an abomination, but more specifically that Vue.js uses <templates> which are very close to web components and will make that transition easy in the future, if and when wide-spread support for them ever drops. I digress.

Setting Up

It’s worth noting that we’re using Node v7, which supports most ES5 and a lot of ES6 syntax, with BabelJS thrown in to fill the gaps.


I always start my Koa projects with a few base modules: koa (duh), koa-router, and koa-static. koa-static allows you to specify and serve one or more directories as static assets - a necessity. koa-router typically handles app routes; that is to say the different endpoints for your app. The code is pretty straight forward, here’s a basic app.js:

'use strict';
import 'colors';
import Koa from 'koa';
import serve from 'koa-static';

const app = new Koa(),
  port = 3000;

  .listen(port, () => {
    console.log('Server Started ∹'.green, 'http://localhost:'.grey + port.toString().blue);

export default app;


To start off a project with Vue, we used vue-cli. That allows us to create boilerplate apps. Since we’re running with scissors here, we jumped right in and went with the simplest template.

$ vue init webpack-simple .

That gives us a basic (as in pumpkin spice latte) Vue app which displays a single page at index.html with a logo and some links. That also generates the App.vue file, which is the main “Vue file” for the app. All of that resides in src now. That’s all well and good, but what about that Webpack file created?

Enter Webpack

Getting a Vue app working right means bundling correctly. We use Webpack, but there are a lot of examples out there with Browserify if you prefer that. Webpack is a wonderful bundling tool and can perform a host of functions. So much so that it can be considered a full-fledged build tool. You’ll need a webpack.config.js file to kick things off:

And then you’ll need Webpack itself:

$ npm install webpack -g

You’ll note that we did a few things different with webpack.config.js, beyond what the vue-cli generated for us; moved assets to assets and introduced a Webpack Plugin to combine CSS in Vue files into one single CSS file to be served by Koa.

Tying it together

If you’re following our example and using Babel as well, you’ll need a Node entry point file to set Babel up for development. We named this index.js:


Assuming you have a solid .babelrc and your dependencies setup correctly, you’re ready to try running this beast. First, fire up Webpack and create your bundles:

$ webpack

Assuming everything succeeded, you’re ready to start the server:

$ node index

And you should see something like this in your console:

→ node index
Server Started ∹ http://localhost:3000

Hit that address in your browser and you should see the Vue demo app. How do you like them apples? I love ‘em.

Running With Machetes

We’ve conquered scissors, let’s get silly and run around with something larger and sharper - in a following post I’ll walk through using middleware with Koa2 to allow live development and Hot Module Reloading. That means you don’t have to restart your server to rebuild your bundles, and you see changes nearly instantly. It’s cool, right?


Originally published at on November 3, 2016.

koa2 1 node.js 4 open source 64 vue.js 1 webpack 1
Gilt Tech

Watch Gilt's QCon New York talks

John Coghlan conferences

Held each year in June, QCon New York is one of the world’s leading software development conferences. This year, we had speakers from HBC Digital present how our teams work and how we have leveraged containers.

What we’ve learned about building great teams and improving team communication

Heather Fleming, our VP, People Operations & Product Delivery PMO, delivered a talk on two frameworks that can be used to improve communication, increase empathy and establish the psychologically safe environment a team needs to thrive. She also demonstrates how we build teams around initiatives using a “Team Ingredients” framework that focuses on each individual’s strengths and talents and what they contribute to the team.

Watch here: How to Unlock the “Secret Sauce” of Great Teams

What we’ve learned from using container technology at HBC Digital

Our SVP, Engineering Adrian Trenaman’s talk provides detailed examples of how HBC Digital has used Docker and where container technology has paid off and, pragmatically, what aspects of the technology haven’t panned out as they thought they would.

Watch here: How Containers Have Panned Out

communication 2 team building 2 containers 3 docker 3 adrian trenaman 1 heather fleming 3
Gilt Tech

Where to find our team in October

John Coghlan meetups

Here’s where to find Gilt and HBC Digital this month:

  • Oct 11 - Dana Pylayeva, Agile Coach, is leading a Product Discovery Game Workshop at the Agile/Lean Practitioners Meetup - RSVP
  • Oct 13 - Sophie Huang, Product Manager, is on the “From Downloads to Daily Active Users” panel at the 🍕🍺📱 (Pizza + Beer + Mobile) Meetup - RSVP
  • Oct 18 - Justin Riservato, Director of Data Engineering & Data Science, is on the “Push Data to Every Department” panel at Looker Join - SOLD OUT
  • Oct 18 - We’re hosting the HBC Digital Technology Meetup featuring Tom Beute, Front End Engineer, and Jared Stetzelberg, UX Designer, talking about “Creating A Live Styleguide: Bridge the Gap Between Tech & Design Teams” - RSVP
  • Oct 25 - We’re hosting the Dublin Swift Meetup at our Dublin office. This meetup will feature 3 great speakers including our own Ievgen Salo giving a talk on Advanced Collection in Swift. - RSVP
  • Oct 26 - We’re co-hosting the Dublin Scala Users Group with our friends from the Functional Kats Meetup. This Meetup will feature Juan Manuel Serrano on Scala and be held at Workday’s Dublin office. - RSVP

See you soon!

agile 6 product 6 data 26 john coghlan 2
Gilt Tech

iOS Custom Gesture Recognizer

Paul Lee ios

As part of our Mobile team’s ongoing effort to introduce more Swift-based pages in the iOS app, I recently started working on a full screen gallery feature on our Product Detail Page (PDP). The feature is similar to the typical full screen photo gallery users will recognize from many other apps, including Apple’s Photo app and e-commerce applications featuring full screen view of product images.

Quick Way to Exit Full Screen View

In order to offer the best shopping experience, we wanted to make sure our customers can easily enter and exit the full screen image view from PDP. Entering full screen view is easy - customers simply tap anywhere in the photo area. For exiting full screen view, we wanted to let customers scroll vertically with a single finger to zoom-out and, if enough zoom-out level is reached, exit full screen. Performing double finger pinch-in gesture to zoom-out beyond threshold level will also close the full screen view but single-finger gesture is much easier and more natural while holding the phone in one hand. It also helps customers browse through products faster. This is crucial when every second counts for grabbing last minute inventory on Gilt’s flash sales!

Adding a New Gesture Recognizer

When customers are on full screen image view, they can scroll left or right to browse the next or previous image. That screen movement is handled through UIPanGestureRecognizer - one of the built-in gesture recognizers in iOS. Gesture recognizers provide (x,y) coordinates of users’ finger movement as a gesture is performed. New (x,y) coordinates are captured and passed to application every 16.7ms, or 60Hz.

To allow browsing to the left or right, PanGesture listens for x-coordinate change in a user’s finger movement and moves screen to the left or right accordingly. It ignores y-coordinate change. For example, if a finger moves diagonally to the left, it creates the same effect as moving horizontally to the left as change in y-coordinates are ignored.

In order to support scroll-down-to-zoom-out-and-exit function, we added a new gesture recognizer that ignores x-coordinate changes and only recognizes y-coordinate change. That is, if a finger moves diagonally to the left, it will zoom out the image and, once enough zoom-out is applied, exit the screen. The application will zoom out images gradually as the y-coordinate changes, ignoring all x-coordinate changes.


We now have two gesture recognizers on the same screen that perform opposite work of each other. One listens to delta X and ignores delta Y. The other one listens to delta Y and ignores delta X. Given how dense iOS device screens are and how fast finger movement is captured, it is very unlikely that a user’s finger movement is perfectly horizontal or vertical. Thus, we assume that we will always see diagonal movement, which changes both x and y coordinates at the same time. If a finger moves diagonally, we cannot let both gesture recognizers be activated because we must perform only one of the two actions - scroll to next/previous image or scroll-to-zoom-out.

We know we have to pick one of the two recognizers very early on when gesture begins. That way, we know what to do with subsequent x, y coordinate changes. Interestingly, customers expect that too. They understand that if they start horizontally scrolling a page, the vertical change in their finger movement won’t have any effect while horizontal scroll is being performed. The same goes for scroll-down gesture. They expect that once their intention to scroll down is recognized, any change in horizontal movement during the rest of scroll would have no effect.

The question then is how do we read user’s intention very early in their finger movement and pick the right gesture recognizer to activate?


The answer can be found in the first two set of coordinates obtained. We obtain the very first two set of coordinates and if delta Y > delta X, then customers’ intention is to scroll down. If delta X > delta Y, the intention is to scroll to the left or right. These two set of coordinates are obtained within a fraction of a second as mentioned above and thus the distance covered on the screen will be extremely short. Yet, this is indeed how users tell us what their intention is.

To include such decision process as part of gesture recognizer, I created a new custom gesture recognizer named VerticalPanGestureRecognizer. This recognizer will perform the above work at the very beginning of a finger movement and register itself as a success or failure depending on whether or not delta Y was greater than delta X. The regular horizontal movement is captured by UIPanGestureRecognizer and this recognizer is conditioned to activate only if VerticalPanGestureRecognizer fails.

I am sure all of us have come across mobile applications that support multiple gestures on the same screen. It is easy to take for granted that these applications detect exactly what our intention is. With all of the above in mind, now we can have a little more appreciation for all such convenience!

ios 6 gesture recognizer 1 paul lee 1
Gilt Tech

New Gilt HQ

John Coghlan culture

The New Gilt HQ

Woohoo! Gilt and our colleagues at HBC Digital just moved into brand new offices! Our new digs are in Brookfield Place, a complex of office buildings across West Street from the Freedom Tower in Lower Manhattan. There’s a lot to love about the new space.

The office

It is great to have all of our NYC-based HBC and Gilt people in one location (we have teams in Dublin, St. Louis and Jackson and some remote engineers, too). We’re confident working side-by-side will allow us to better integrate our teams and better leverage our strengths.

Everyone is also really stoked about the views. The floorplan was designed to maximize the views and natural light by keeping the workstations and common areas on the perimeter while offices and conference rooms are in the center of the floor. Our location on the water provides great (I mean really great) views of the Statue of Liberty, New York Harbor, the Hudson River, Lower Manhattan and New Jersey.

The floor has dozens of conference rooms, a pantry, two large collaboration spaces and room for about 320 employees. Our ping pong and foosball tables will be arriving shortly.

The design of the space is clean and minimalist with lots of white and grey touches. Everyone is loving their new super comfy Herman Miller Aeron chairs and the cool little sofas in the collaboration spaces. We have some nice portraits on the walls already and our creative teams are working on a mural for one of the bigger walls to give the floor some more character.

The neighborhood

Brookfield Place is an awesome place to work. We’re right on the water and there is a marina with a sailing school and a handful of yachts right outside our doors. Our building is surrounded by grassy parks with volleyball courts, basketball courts and a skatepark in walking distance. The waterfront is car-free which gives the area a quiet and peaceful vibe.

When it comes to food, the variety is amazing. In our building alone we have the huge French marketplace Le District and Hudson Eats, a food hall with a bunch of NYC hot spots like Chop’t, Mighty Quinn’s, Num Pang, Umami Burger, Dos Toros and Blue Ribbon to name a few. Around the neighborhood, we have Shack Shack, Parm, a bunch of great coffee shops, multiple Starbucks (of course) and Eataly, which just opened across the street.

Other area amenities include an Equinox gym, tons of shopping, waterfront bars, Citibike stations, bike parking in our building and a ton of transit options.

The welcome

Of course, a new office needs to get broken in and People Operations was on it. We had breakfasts, lunch, a champagne toast and a watermelon social to help keep the excitement level high and give everyone a chance to meet their new neighbors since this was the first time our Gilt and HBC teams would be fully integrated on the same floor. The events were a hit and everyone seems be settling in nicely. Mission accomplished.

The invite

Want to see the new space for yourself? Stay tuned to our blog for info about upcoming tech events we’ll be hosting in the new space.

office space 1 culture 29 john coghlan 2
Gilt Tech

New open source project: scala-fedex

Ryan Caloras open source

We recently made the decision to switch from Newgistics to FedEx SmartPost for customer returns at Gilt. A couple of factors contributed to the decision, but the prettiness of FedEx’s API was not one of them - it’s not exactly the most developer friendly API you can find.

FedEx Web Services are a collection of APIs to do everything from generating shipping labels to tracking packages. Unfortunately, they’re still using SOAP and WSDLs! That means poor support for a modern language like Scala. Their sample Java client contained a bunch of unfriendly Scala code (e.g. Xml, blocking requests, and Java Classes rather than native Scala).

Enter scala-fedex

Using scalaxb we were able to generate a native non-blocking Scala client from FedEx’s WSDL. We then added a wrapper to further reduce the boilerplate of the raw generated client. The final result being a thin async Scala client for FedEx’s Ship Service API. It also provides a much cleaner example of usage than the previously mentioned Java code. We can now use this to generate FedEx return labels on Gilt using native reactive Scala code!

To support the community, we decided to open source and publish scala-fedex. You can find more specifics on the scala-fedex repo.

scala 14 fedex 1 open source 64 web-services 1 Ryan Caloras 7 John Coghlan 1
Gilt Tech

Rookie Summer

Team Rookie internship

The Summer Internship #TeamRookie

What can four interns do in a ten week internship? A lot, as it turns out.

With some help from the fantastic team led by Kyle Dorman, we built out a complete backend and frontend iOS app and had a ton of fun in the meanwhile. Here’s a snapshot of our summer experience.

Our internship began with two weeks of heavy learning. We were going to be building a mobile application using Swift, Scala, and the Play framework, but most of us had no prior experience with any of these tools. So our mentors led us through lab assignments to get our feet wet. We built a few simple iOS apps and a small Play application that used the Gilt Public API. As we became familiar with the languages and tools we would eventually use to build our intern project.

After our brief introduction to software development at Gilt, we started on a project of our own. Our mentors introduced us to Agile sprints, and we were off. Our progress was slow at first, but kicked up near the end, and on the last day of development we finally got our finished app deployed.

While we worked a lot this summer, Gilt made sure that we had tons of fun as well. Every Friday, we left the office early to explore a new part of New York. We went up the Freedom Tower, walked the High Line, and saw a musical on Broadway, amongst tons of other fun activities. We even had fun inside the office. We had weekly lunches with different teams across the organization, and we enjoyed random festivities like Cheese-mageddon, where tech samples more cheese than is probably healthy.

So, what was our actual project for the summer? The Gilt Style Quiz is a fun, playful way for users to start interacting with the Gilt iOS app without making a purchase. At the same time, the app gives Gilt a chance to get to know our users better as well. Through a series of style related questions, we are able to collect both brand and product category affinities for a user and are able to, as a result, better personalize the shopping experience for our users. As a team, we took complete ownership of the project and built the app from ground up. We began by developing the API and data models, and then we split up to tackle the front and back ends of the project.

What about Gilt Tech made the internship so cool?

Micro service architecture

Gilt uses micro services architecture to back the business operations. Because our service could be small and totally independent, we were able to make all of the design decisions in architecting the backend, super cool as an intern! We created a RESTful API with apidoc, an opensource project for declaring the models and resources of a RESTful API that comes with a suite of client generators.

#### Mentorship

Gilt provided a lot of resources to help us succeed and grow this summer. Right from the start we were introduced to individual mentors who helped us every step of the way, from learning Scala, Swift, and the magic that is AWS, to polishing out our product in the final week. Throughout the summer we had the opportunity to dine with the various tech teams and learn about the architecture supporting the Gilt backend and frontend. Erica also organized for us lunches with several executives from within Gilt and HBC, giving us firsthand insight to what drives the company.

From a project perspective, we had the chance to work with an amazing product manager, Hilah Almog, who defined our metrics of success and the scope of the application, as well as with a designer, Jose Salamone. It is easy sometimes to get caught in a cycle of code, test, and deploy without stopping to think of who is going to be using the product. However, getting the chance to work with non-engineers really helped keep the project in perspective. We weren’t writing code just to develop our skills in Scala and Swift or even to gather data for the personalization team. Primarily, we were developing a product to enhance customer satisfaction, to show our users that shopping on Gilt is a fun, enjoyable experience, and to streamline their transition into using their personalized product feed. While developing our technical skills was important, one of the key takeaways from this summer was definitely that it is crucial to keep your users in mind while developing!


Gilt has a unique, forward-thinking culture. The company constantly evaluates the tools it uses, and it is always open to exploring new technologies. We were exposed to this at the quarterly architecture council, where all the engineers spend a day discussing the current state of the Gilt technology stack and exploring possible new directions for tech.

Gilt is also committed to open-source and we made use of some Gilt open-source technologies in our project. The Cleanroom Initiative is an open-sourced codebase in Swift providing help with data transactions in our application. We also used an open-source apidoc Swift client generator and worked with the owner to make some additions to the project.


Throughout the summer we were exposed to a host of skills that eased the software development process. The adoption of standardized git workflows and explicit communication on project status through Agile sprints accelerated the development of our project across the short time frame. If we listed all we learned this summer it would take about, oh say, ten weeks, but needless to say this was a summer that we’ll all remember for a long time.

internship 3 mobile 22 team rookie 1
Page 1 of 66