Our thanks to all in the Dublin Scala User Group who attended the DSUG meet-up in our still shiny new Gilt office in Ballsbridge. Gilt’s own Ugo Matrangolo artfully dismantled the Cake Pattern in Scala, and proposed an alternative approach to dependency injection using the Scaldi framework (slides below). Julien Sirocchi from Workday also did a great presentation on ‘All You Don’t Need to Know About Type Classes’. Cameos from Functional Kats and Citi’s Aman Kohli, coupled with the customary selection of pizzas and craft beer, made for a great night! Thanks all for coming - we’re looking forward to welcoming the Dublin Scala community back soon for our free Scala Training in April.
For more than 5 years, Gilt’s Mobile team has been developing and using a platform that lets its iOS applications adapt to server-side changes long after they’ve been released.
This platform has been the backbone of an application that has served millions of users, handled hundreds of millions in sales, and has been consistently highly-rated in the App Store and repeatedly featured in Apple keynotes.
Today, we’re excited to reveal the official open-source release of this platform: announcing the Mockingbird Data Environment 1.0!
It is a common scenario for iOS app publishers to have a population of users running old application versions. Often, users are stuck on old versions because the current version requires a release of iOS more recent than their hardware will support. Such users won’t be running your latest app version until they buy a new device, assuming they ever do.
For some types of apps, this isn’t a big problem. But for apps that must communicate with network-based services, having a wide variety of old versions out in the wild makes it difficult to evolve and maintain your services.
Eventually, you will be faced with accepting one of these tradeoffs:
Do you drop support for old versions, knowing that there’s a risk of severing valuable relationships with some of your users?
Do you take on the expense and difficulty of maintaining and operating a growing number of legacy backend services over time?
Or do you resign yourself to never evolving your backend systems—or doing it much more slowly than you’d like?
The purpose of the Mockingbird Data Environment is to free you from having to make these compromises.
To experiment with the Mockingbird Data Environment in your own iOS project, use CocoaPods and add the following line to your Podfile:
pod 'MBDataEnvironment'
Then, run pod install from within the directory containing your project’s Podfile.
The Mockingbird Data Environment is available for use under the MIT license.
Yesterday and today, Gilt’s tech team in Dublin hosted free, all-day Docker bootcamps taught by the generous folks at DemonWare. DemonWare’s instructors covered all the essential Docker basics, from listing images to caching, and did a fantastic job doing it. Several Gilt engineers joined technologists from other companies in Dublin in taking advantage of this helpful Docker primer. Thanks, DemonWare!
Gilt Senior Manager, Business Systems Patrick Richardson shares some of his favorite tools for getting things done. Add these to your own toolbox, then send us your feedback on what works for you. We’re always looking for ways to improve, so your experiences matter to us!
The mission of Gilt’s Business Systems Management team is to guide the process of matching technology and process solutions to business needs, so that the team can achieve the highest possible ROI in technology and levels of efficiency. Our customers are our coworkers: As such, we focus on finding internal tools and building systems to help us discover business opportunities, design solutions, educate the rest of the company on how our business systems and processes work (or should work!), and document and communicate changes.
For getting our work done, my team and I depend on these tools:
I begin each workday by opening four applications: my email, my calendar, Atlassian’s JIRA, and JackDB. The first three should be familiar to anyone working in PMO or an Agile Tech organization. JackDB, however, may not be as familiar to you. It should be!
JackDB is a browser-based SQL-query tool that makes it incredibly easy for anyone at any technical level to quickly access your company’s databases and make data-driven decisions. I’ve used similar applications in the past, but have found JackDB to be, by far, the easiest to use. And as a bonus, our Security Team at Gilt loves its two-factor authentication, role-based access, and system audit logging features.
Use JackDB to quickly research data, such as the number of purchase orders by buy type for a particular division in the last six months.
Like other BSMs I know, I’ve tried about a half dozen applications for drawing process documents during my career, and still haven’t found the perfect tool. LucidChart comes pretty close. It’s web-based, so there’s nothing to install — and I can easily use it when working from home. It’s collaborative, so my team can share diagrams and comment on each others’ work. It’s affordable, so there’s not a huge hit to your budget. And it makes switching incredibly friction-free by allowing you to import your Visio or Omnigraffle documents.
LucidChart makes its product so useful, that it’s practically impossible for you to not give it a try.
Use LucidChart to diagram current-state and future-state processes so that you can educate your peers, highlight areas of change, and show the business impacts of these changes (such eliminating or introducing new steps in the creative process that create efficiencies).
Nearly every day I encounter an assumption about how a particular tool or system works. The assumption can come from a business stakeholder, an engineer, the application support team, or even myself. As a subject matter expert on our proprietary ERP system, it’s my job to understand and educate people on how our tools work. But it can be difficult to stay current when we’re constantly updating and writing new code to keep up with evolving business needs. So when in doubt, I use OpenGrok to go directly to the source code and tell the truth about what’s really going on. (If you’re in a BA or BSM role and don’t already have access to your source code, then stop reading RIGHT NOW and get it. Referencing the source code is highly valuable when discussing current state vs. future state, or when proving/disproving assumptions about how things work.
Use Opengrok to get to the truth about how code works, such as the attributes that determine how purchase orders are routed to your distribution centers.
When I initially proposed adding Google Analytics tags to our internal Admin system more than a year ago, I was greeted with mild skepticism. But it didn’t take much to convince the engineers on my team how valuable it is to understand just how our employees are using — or not using — specific tools. I primarily use GA to help prioritize maintenance tickets and build business cases to turn opportunities (for example, overhauling merchandising tools) into projects by looking at usage.
Use Google Analytics to determine the top-used tools in your Admin system ranked by page views and session duration.
As a BSM, it’s critical I have instant access to our data so I can quickly answer business stakeholder questions, research opportunities that’ll help fund our future, design technical solutions, or just satisfy my curiosity. Looker’s self-service reporting platform makes it easy to do that, and to share my findings with others throughout the organization by sending Looker URLs to reports and dashboards instead of Excel files. I’m able to duplicate a vendor dashboard of eight existing reports and share it with my team in less than a minute!
Use Looker to build reports and dashboards on inventory levels, sales history for products by condition code, and other aspects of your business of prime interest to your business stakeholders.
This is the first in a series of blog posts focused on tools we use at Gilt. Check back soon for more insights from other members of our tech team.
Based on the feedback we receive from Gilt customers, we know that fit and sizing varies greatly between brands—which can make finding the right size very challenging. We always want our customers to feel great about their purchases and confident that an item will fit. With this in mind, we are excited to announce the launch of Fit Predictor: a new technology from our partners at Secret Sauce.
With Fit Predictor, simply tell us which sizes fit you best in some (or all) of your favorite brands. Based on the stats you provide, and the items from your fave brands that you select, we will calculate and recommend the right sizes for you. Here’s how it works:
While checking out select items on Gilt, you will notice the Fit Predictor above the size selections:
Click “calculate your size” to choose a brand that you know, an item type, and the size that fits you:
Based on your input, Fit Predictor will recommend the size that will best fit you for the item you are currently viewing:
The more sizing information about your favorite brands that you share with Fit Predictor, the better predictions we can make. Over time, build up your fit profile and receive the most accurate recommendations:
With a Fit Profile, every time you navigate to a product that is enabled by Fit Predictor, we will automatically suggest the best size for you:
We will be working hard to roll out Fit Predictor to as many items as possible, so you can always take advantage of its magic!
We launched Fit Predictor as part of our mission to provide the best shopping experience for our members. Let us know what you think of this and other new features by emailing us at [email protected]!
For our first Dublin Scala Users Group meetup of 2015, we’ll have two great technical talks, hot pizza, cold beverages, and, as always, our comfy-n-colorful beanbags (go here to view them). Our speakers for the night:
Gilt Principal Software Engineer Ugo Matrangolo will discuss the implementation of the Dependency Injection pattern in Scala, and will try to offer an honest (although opinionated) view of what works and what doesn’t with Cake. He will also introduce ScalDI: a new framework that is rapidly gaining popularity among people who want a quick and easy DI implementation without using the Cake pattern.
Julien Sirocchi of Workday will talk about type classes, and will show how Scala programmers don’t need to understand them to use them
The SUG will meet up on Thursday, Feb. 5 at Gilt’s office in Dublin 4; go here to RSVP.
"[R]elying on data and math alone won’t suffice when it comes to providing the best user experience," writes Gilt Senior Software Engineer Brian Ballantine in his new column for VentureBeat. “To get personalization right, you need heuristics: a set of problem-solving techniques that rely on experiment, experience, and sometimes even wild guesses.” What are heuristics, and how does Gilt use them to optimize our personalization efforts? Go here to find out. :)
When implementing “lazy val” class variables in Scala 2.10, keep in mind that lazy vals hide some plain-old synchronized block behind a nice-looking syntax. At Gilt, more and more of our stuff is Future-based, and increasingly more of it executes in Scala’s shared ForkJoinPool under the assumption that it “behaves.” Sometimes these worlds collide, however, and “lazy val”-guarded calls (which are synchronized blocks in disguise) end up being thrown into global FJP. And worse, they may some times be highly-contended.
There are good reasons to use Futures and async IO, and good reasons to use lazy vals. You just need to be very, very careful if and when you end up mixing the two, because they are a bit tricky to understand at best and may lock up your system at worst.
Of course, the easy position to take is, ” just don’t do it! “:)
The rule of thumb: If code that initializes your lazy val is non-blocking and very fast, it’s most likely OK and could be good way to defer creation of heavy objects (like thread pools). OTOH, if your lazy val is initialized from a Future, or the result of some remote service call(s), that can easily turn out to be problematic when ‘normal’ code that tries to de-reference those values ends up (unwittingly) making a blocking call inside a (perhaps shared) FJP. Think twice if that’s where you find yourself—there are often better alternatives. —Content (and most words) by Andrey Kartashov, Gilt Principal Software Engineer
If performance issues are making you feel like King Kong—i.e., disgruntled and prone to going on a rampage—then head on over to the Empire State Building next Wednesday and get some relief. Gilt Lead Software Engineer Gregory Mazurek will appear at the next New York Front End Coders meetup to explain how Gilt analyzes web performance using RUM and synthetic monitoring as well as the W3C Performance Timing API. He’ll give a couple examples of recent performance issues at Gilt and how our tech team has integrated performance into our workflow. By the end, you should feel rather enlightened and calm—more like Curious George than a monster gorilla.
Also on the bill will be Nathaniel Lee, who will discuss “Leveraging Functional Programming in JS.” Go here to RSVP (and do it before Monday, January 26).
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
In software development…
In order to satisfy the customer you have to truly understand what the customer needs.
Sometimes what a customer wants is very different than what a customer needs.
Keep asking “Why? Why? Why?”
This requires the customer to be very much engaged in what is happening. They need to be able to express whether or not they are satisfied in real-time.
Early and continuous delivery of valuable software is pretty difficult to do.
What is “early”? Perhaps “incremental” is more appropriate. I’m assuming this wasn’t intended to be “early” in the traditional, calendar-time based meaning.
Continuous delivery == constantly changing, hopefully for the better.
There is no such thing as “scope creep” in Agile!
It is of value if it satisfies the customer, therefore the customer must determine what “valuable” means.
But… If delivery is continuous, when are we “done”? Perhaps never. Satisfaction is a tricky beast.
In life…
In order to be satisfied, you must actually understand what you really need to be happy.
What you want is not necessarily what you need.
Perhaps in order to get at the core of what you really need, you have to ask myself “Why do you want X?”
You can’t “check-out”. In order for this to work you need to be present and engaged in your life and incrementally improving it.
You also need to start NOW and continuously deliver on those needs in the form of changes for the better.
"Working software" in life is a means by which the need is satisfied. This could be anything from eating well, getting enough rest, to treating yourself with the same kindness and respect you give your friends.
The key is to first really understand what your needs are — what will it take to be satisfied?
And finally, admitting that you am a work-in-progress. There is no “done”.
