We are excited to announce the public release of a package we’ve been using internally at Sift to handle our […]
Sift is excited to announce that we’ve been named one of Built In Seattle’s 2019 Best Places to Work! This […]
Jun Qian’s typical day consists of thinking through real-world machine learning applications, hiring brilliant engineers, and digging through incomparable types […]
A few years ago, the advice for keeping your page fast was to keep your page weight down. These days, […]
In this blog post we detail how Sift has begun leveraging deep learning (in the form of RNNs) to improve our ability to detect fraud.
At Sift Science, engineers train large machine learning models for thousands of customers. We need processes and tools to do […]
By now, you’re probably familiar with the benefits of splitting up your app’s javascript into several smaller files through code […]
TL;DR: We can transform the score distributions of new models to match those of old models, while preserving the new […]
Sift Science’s iOS SDK enables mobile applications to send us device properties and application lifecycle events for use in fraud […]
We’re very proud to sponsor Startup ML’s conference on Putting Deep Learning into Production, being held Jan 21, 2017. While we […]
I remember being intrigued by Smashing Magazine’s post this summer about using PJAX to effectively turn static markup websites into […]
We started Sift Science over 5 years ago with the mission to improve outcomes with data and create a safe, […]
In the first post in this series, we looked at how coding within the React paradigm could lead to poor […]
Adventures in React Performance DebuggingRecently I read Benchling’s 2-part series in debugging performance issues in React, and it really echoed the issues and solutions that I’ve been working through on the Sift Science Console. So I was inspired to chime in with some of my own React performance debugging experiences in what may become a short series itself.
Here at Sift Science, we just completed another big step in our ongoing marketing site redesign, overhauling the homepage and replacing old landing pages with [prettier, responsive, and more performant ones][1]. While the big performance improvements aren't quite ready to showcase yet (check in soon for more on that), I realized that there are a few custom Sass mixins and placeholders that I rely on heavily for responsive development—I'm not actually sure what I'd do without them—and I thought I'd share them here along with some CodePens so that other people might also take advantage of them!
In the first post of this series, we gave an overview of Sift Science’s architectural migration to React and Dropwizard. We followed up with some best practices for scaling React in a production setting and some tips on using React with D3. Today’s post will chronicle the front-end migration process of moving from Rails + Backbone + Marionette + Handlebars to a static Backbone + React console, and the challenges we encountered.
A little less than a year ago, the Sift Science Console Team decided to migrate its Backbone and Marionette Views to ReactJS see also our post on specific React tips we learned along the way. Among the many facets of a piece-by-piece migration like this was figuring out how best to manage (err...'reactify') our d3 charts. There were already a couple good reads/ listens on this topic—with very different views on the responsibilities of each library—which we found quite helpful in establishing our own approach.
Two years ago, we publicly launched our first fraud product with the goal of making it easy for anybody to leverage the same machine learning technology that protects the largest internet retailers. That product had a very simple interface: we provided one API for sending data about user behavior and another to query the fraud score of a user. But as our customer base grew, we needed better internal tools to debug and surface customer issues.