#Ubar west end install
#Ubar west end code

PRIDE Your code being publicly available instills a sense of pride.So, why go through this exercise of creating open-source modules? This is where the learnings happened that ultimately forced us to think better and harder about our work. Are we expecting that other people are going to use UBAR on their websites? Frankly, no. We did so without sacrificing any internal requirements or features. Our goal was to write a front-end module that could be easily consumed both by our current system and externally. We created UBAR (Unidirectional Browser App Resolver) as an open-source first module that behaved as OAFE. OAFE was a perfect candidate for an open source project because it needed to be implemented on two completely separate code basis (Gilt and Gilt City). It tries to be the best experience for people who want to be redirected and people who want to stay on the mobile web. As a result, our implementation of OAFE is a little complex.

#Ubar west end install

OAFE is one of those mobile-web user experiences you see that asks “if you’d like to install the app.” Internally, we have a lot of discourse about whether this is a good experience for our users or not. We used a project that we had just finished called OAFE (Open App From Email) as the basis of this experiment. The Special Operations team (Kyle Dorman, Jose Sanchez, Archana Kumar, and myself) set out to create a pattern by which we could open-source modules that could be used by the greater tech community without sacrificing any characteristics of the module had it been developed internally.

But, it makes open-sourcing any of these individual modules just about impossible. And once the learning curve is conquered, we defend its design while sipping our orange Kool-Aid. These modules depend on each other in ways that would make spiders jealous. And, our internal requirements make it necessary that we wrap requirejs which means we oftentimes aren’t using off-the-shelf versions of each module. We wanted to bridge this gap and decided to do so through a tiny front end initiative we called Open Source First.įor example, our front end architecture consists of over 100 requirejs modules that are bundled and served by an in-house legacy build system that is as tightly coupled as a ball of rubber bands. This makes open-source contributions tricky because our potential projects and tools are so tightly coupled to our systems. But like most other companies, we have internal systems that are very specific to Gilt. At Gilt, our open-source contributions generally come in the form of tools that we use internally that we think have value to the rest of the tech community.