# Addepar Addepar Engineering + Design - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Ember Table 2.0 Release DevFeed: [Ember Table 2.0 Release]() Original publisher: [Read original article]() Author: Cory Forsyth Published: 2019-08-12T17:52:23Z Content type: release Language: en Sources: [Addepar]() Topics: [Ember](), [Library](), [Sorting](), [Documentation](), [Testing](), [migration]() Tags: [2](), [datatables](), [documentation](), [ember](), [feature](), [features](), [migration](), [performance](), [release](), [sorting](), [table](), [testing]() ### AI overview Addepar announces Ember Table 2.0, a ground-up reimplementation of its data table library with a new API, improved performance for large tables, and greater flexibility. The release adds features including nested subcolumns, occlusion rendering, sorting, resizing, and interactive, versioned documentation. ### Source excerpt I'm excited to announce the release of Ember Table 2.0. This release is the culmination of more than 18 months of effort across several Addepar developers and external contributors. This release represents a ground-up re-implementation of Ember Table with a new, modern, and future-compatible API. At Addepar, the new Ember Table 2.0 ("ET2") brings even better performance on large tables and its enhanced flexibility is a better fit for the advanced use cases that Addepar clients have. Ember Table in use in the Ember Inspector extension Over the past year we've adopted ET2 into much of Addepar's product, and in an upcoming release we will have completed our migration away from the legacy version. That milestone, and the corresponding stability requirements, merit an official major release. Since this release diverges significantly from Ember Table 1.0, we renamed the original version of the library and repo to "ember-table-legacy" to make it easy for legacy codebases to continue using the older version. If you've been waiting to try ET2, now is a great time. It's a powerful and flexible data table library designed to be approachable yet full of features to accommodate complex needs, such as: fixed headers, footers, and columns row selection and sorting tree tables with group collapsing column resizing and reordering nested subcolumns (an all-new feature in ET2 that supports complex table headers, for example to create pivot tables) ability to render thousands of rows performantly via occlusion rendering (leveraging vertical-collection) compatibility with Ember versions 1.13 through 3.10, with a progressively improved API exported test object for testing tables in your app Ember Table supports sorting, column reordering, nested data, and more Additionally, significant effort went into revamping ET2 documentation. The docs use ember-cli-addon-docs so that they are searchable and versioned, with expanded sections and interactive demos. To start using the new ET2, add `emb ## Bringing the 201 Created team to Addepar DevFeed: [Bringing the 201 Created team to Addepar]() Original publisher: [Read original article]() Author: Alex Navasardyan Published: 2019-01-28T18:35:05Z Content type: news Language: en Sources: [Addepar]() Topics: [Ember](), [Tech Debt](), [Front end](), [code productivity](), [web applications](), [JavaScript]() Tags: [adopting](), [announce](), [ember](), [front-end](), [javascript](), [productivity](), [team](), [tech-debt]() ### AI overview Addepar announces that the team from 201 Created, a JavaScript consulting firm, will join the company as full-time staff. The team will help modernize Addepar's older Ember.js web application codebase and form the core of a new internal group focused on web technology improvements, best practices, and front-end developer productivity. ### Source excerpt I'm excited to announce that the team at 201 Created, a Javascript consulting firm, is joining Addepar in February. Seven months ago we asked them to help modernize Addepar's web application codebase, and now we're welcoming Matthew Beale, Cory Forsyth, Jonathan Jackson, and Kevin Pfefferle as full time staff. Addepar's original product was a Java Swing application. Seven years ago we started rewriting that application onto the web platform with Ember.js at its core. We were motivated by the promise of faster feature development, an ability to improve usage analytics, to quicken the app's loading speed, automate testing, and to provide better security to our users. When the codebase was new, modern, and smaller those promises were delivered on. But after years of a hard focus on features to ensure Addepar's adoption by the market we've accrued some tech debt. Addepar's main codebase runs on an older, unsupported version of Ember.js making it difficult to leverage the latest productivity improvements enjoyed by the wider Ember.js (and web development) community. Working with out of date software makes documentation and education a constant challenge for our front-end developers. To maintain the benefits of Addepar's original web refactor on what is now a much older and mature codebase, we're forming a new internal team at Addepar. This team will focus on practical web technology improvements, adopting best practices, and accelerating front-end developer productivity. We're looking forward to having 201 Created's team form the core of this group, and to leveraging their technical knowledge and background in pairing and training. We're excited to welcome Matthew, Cory, Jonathan, and Kevin to our team at Addepar! You'll find them and other Addepar staff at EmberConf 2019. Read more on this change at the 201 Created blog. Interested in working with us at Addepar? Visit addepar.com/careers. Bringing the 201 Created team to Addepar was originally published in Build@Addepar ## Ember CLI Addon Docs: Shared Documentation for the Ember Ecosystem DevFeed: [Ember CLI Addon Docs: Shared Documentation for the Ember Ecosystem]() Original publisher: [Read original article]() Author: pzuraq Published: 2018-03-07T21:00:37Z Content type: article Language: en Sources: [Addepar]() Topics: [Ember](), [Documentation](), [code productivity](), [JavaScript]() Tags: [automated](), [developer-productivity](), [documentation](), [ember](), [ember-cli](), [emberjs](), [examples](), [experimental](), [full-text-search]() ### AI overview Addepar describes the development of ember-cli-addon-docs, a shared documentation solution for Ember addons. The project addresses limitations in existing tools by providing Ember-focused API documentation, Markdown templates, live demos, versioning, automated deployments, search, and pluggable API documentation generators. ### Source excerpt On our road to modern Ember here at Addepar, we've been hard at work developing a new component library to replace a lot of our older components, such as the now deprecated Ember Widgets library. As anyone who has built a shared toolset of components will know, one of the more tedious tasks faced by a library developer is documentation -- users of the new components need to be able to reference the APIs to know how to use them, and having a single source of truth for your docs is invaluable to developer productivity, but setting up docs in the first place is a lot of hard work! For Ember, part of the problem is that there is no standard documentation solution as of yet. The core Ember and Ember-CLI API docs use YUIDoc to generate docs automatically, but it is an aging library which doesn't have much support for modern javascript features. JSDoc is also falling behind the times lately, and newer doc tools like ESDoc and Documentation.js are still too experimental for widespread use. Moreover, none of these tools targets Ember -- they are meant for generic Javascript usage and don't highlight things that Ember devs need to know, like what arguments a component receives, what actions it sends, or what values it yields. Worse yet, none of these tools has support for live examples and demos. To get those, most addon authors resort to building an Ember app, usually using the test application (or Dummy app) included with the addon. Building an app takes time and effort, and in the end this means that very few addons in the ecosystem are fully documented with good examples and well described APIs. When we started to set up our documentation we ran into all of these issues, and we began wondering where the shared solution was for Ember documentation. As often happens in the Ember community, it turned out others had been wondering this as well! We joined forces with Sam Selikoff, Dan Freeman, and the Ember Learning team to work on ember-cli-addon-docs, a project whose goal is t ## Art of Automation: Striking a Balance DevFeed: [Art of Automation: Striking a Balance]() Original publisher: [Read original article]() Author: Matt Zukowski Published: 2017-11-30T14:06:14Z Content type: opinion Language: en Sources: [Addepar]() Topics: [Automation](), [Finance](), [Transactions](), [data]() Tags: [automation](), [data](), [finance](), [fintech](), [reorganization](), [split](), [transactions]() ### AI overview This article argues that finance cannot be fully automated because corporate transactions are variable and shaped by human creativity, legal constraints, operational costs, and approval requirements. It describes Addepar's approach of combining automation with human judgment and introduces corporate reorganizations as a case study. ### Source excerpt As engineers, we want to automate everything. It's one of our core values at Addepar. There's nothing more satisfying than seeing a huge collection of data neatly line up exactly the way you want it to, with every edge case taken care of and every peculiarity accounted for. The tricky thing, though, is that we're solving the problems of the financial world -- a system that is inherently made up of and built by people. It's laden with incentives for creativity, and we see those sparks of innovation in new products and transactions. This ingenuity is what makes finance special. But the state of perpetual flux also makes full automation impossible. At Addepar, we've decided to embrace the mindset of the financial world. We want to allow people to flex their cognitive and deductive skills, while still using automation as a guiding mechanism. We want to stay flexible and yet harness the power of computers, just like the people-centered system we're trying to model. This approach lets us stay up-to-date. In this blog post, I'm going to dive into one of the most complex and variable financial transactions we encounter at Addepar -- corporate actions -- as well as some of the lessons we've learned about incorporating human insight into our technology. The Challenge of Automating Variations Corporate reorganizations occur often. They can be some of the most high-profile and financially impactful things you hear about: Microsoft purchasing LinkedIn, Amazon purchasing Whole Foods. While certain variations are quite common, these transactions can, and do, get arbitrarily complex. There's a great deal of variance from one to another and it's no mystery why -- the flexibility on what can be done is very high. Of course, you have certain legal constraints (based on the existing assets/liabilities of the company), operational constraints (the more complicated the transaction, the more costly), and then the hurdle of getting board approval. Beyond that, though, it's pretty much an open ## ES Classes in Ember.js DevFeed: [ES Classes in Ember.js]() Original publisher: [Read original article]() Author: pzuraq Published: 2017-11-15T20:01:01Z Content type: tutorial Language: en Sources: [Addepar]() Topics: [Ember](), [JavaScript](), [Web Development]() Tags: [classes](), [code](), [ember](), [emberjs](), [es-classes](), [es2017](), [javascript](), [syntax]() ### AI overview This guide explains how ES classes, class fields, and decorators can be used with Ember.js. It describes the accepted ES Classes RFC, potential benefits such as improved tooling and clearer syntax, and caveats involving currently broken features and evolving JavaScript proposals. ### Source excerpt Classes have been an emerging standard in Javascript for some time now. With features like class fields, private methods and fields, and decorators on the way, pretty soon Javascript will have a fully featured class syntax with capabilities that haven't been available in the language before. While Ember.js has had its own, trusty, custom object-model in Ember.CoreObject since the very beginning, these broader advancements are going to be the future of the language and the web itself, so in time we will have to build out and replace the existing system with one based on ES2017+ classes. If you've been paying attention to Ember RFC process you may have noticed that an RFC for ES Classes was accepted recently. The RFC was very minor: it didn't propose any overhauls or breaking changes to the Ember object model as it stands. In fact, it was really just formalizing an existing oddity -- ES classes work with Ember as is, right now, as far back as Ember v1.11 (and possibly even farther). You can use them today, along with class fields and decorators, and get the benefits of modern JS syntax, including: Better tooling from editors like VS Code and Webstorm Better static analysis tools and documentation generators, like ES Doc Shared code and solutions with a wider ecosystem, including other decorator libraries such as core-decorators Shared knowledge with a wider ecosystem -- no more needing to teach the Ember object model to new developers, they just need to know Javascript and they're good to go A simpler, cleaner, declarative syntax that's easier to understand and makes your code more readable Of course, there are some caveats with switching to classes today. Certain Ember features are currently broken and being fixed as-per the RFC. Others, like class fields, have changed dramatically, and you'll likely need to update your mental model just a bit. This guide will lay out all you need to know about using classes in Ember today, including some new techniques that add additi ## Retrofitting Position IDs to Addepar Non-Intrusively DevFeed: [Retrofitting Position IDs to Addepar Non-Intrusively]() Original publisher: [Read original article]() Author: Calvin Wu Published: 2017-11-08T14:11:00Z Content type: article Language: en Sources: [Addepar]() Topics: [data](), [Graphs](), [Entity resolution](), [integrity](), [import](), [Architecture & Design]() Tags: [data](), [data-pipeline](), [edge](), [fintech](), [graph](), [import](), [integrity](), [mapping](), [node](), [reconciliation](), [validation](), [verification]() ### AI overview Addepar describes its Financial Graph and data pipeline for importing portfolio data from many custodians. The article explains how node matching identifies accounts and securities, connects them through ownership edges, and addresses verification and data-integrity problems through a non-intrusive pipeline change. ### Source excerpt Every day, Addepar's data pipeline consumes portfolio data from hundreds of different custodians and imports it to millions of nodes and edges in our Financial Graph. To ensure that the data can be trusted and used to correctly calculate performance, it's crucial that we not only import it in a timely fashion, but also run verification checks with what already exists on our platform. The data is complex, and data integrity check failures can be caused by a lot of different issues -- for example, missing data, incorrect raw data from custodian, incorrect transaction mapping, problematic validation logic, and incorrect security mapping. As our platform grows, we're continually improving and extending our methods. The following is an example of how we addressed one type of verification problem -- node matching -- by non-intrusively introducing a core change to a critical pipeline. Node Matching The Financial Graph is used to represent the ownership structure of portfolio data, where a node represents an entity (such as a brokerage account, an asset owner, a legal entity, a stock, or a bond), and an edge (or a position in financial terms) represents the ownership relationship between two nodes. The from node is often an account, and the to node refers to the portfolio's holding -- the actual security. When importing data, we need to do a few things: Identify the account node. Identify the security node via node matching. We search for the security node in our system using the security attribute information the custodian provided. The search criteria could be the name of the security or security identifiers. Each security type may have different preferred strong and weak identifiers that drive the matching. Our matching logic may evolve over time as we learn more about the data. This is similar to the entity resolution problem, where we have to identify the same node across different data sources. Find the edge. Once both the account node and security node are identified, th ## Addepar's Migration from Mongo 2.4 to Mongo 3.4 DevFeed: [Addepar's Migration from Mongo 2.4 to Mongo 3.4]() Original publisher: [Read original article]() Author: Elan Kugelmass Published: 2017-10-24T13:11:15Z Content type: article Language: en Sources: [Addepar]() Topics: [Databases](), [upgrade](), [etl](), [Dependency management](), [Replication]() Tags: [data-pipelines](), [database](), [databases](), [dependency-management](), [migration](), [mongodb](), [pipeline](), [replication](), [upgrade]() ### AI overview Addepar describes upgrading its database from Mongo 2.4 (TokuMX 2.0) to Mongo 3.4 as its dataset and stability and performance requirements grew. The article explains Mongo's role in the company's data ingestion and ETL pipelines and why database upgrades are risky because database guarantees and behavior can change between versions. ### Source excerpt At Addepar, we're building the world's most versatile financial analytics engine. To feed the calculations that give our clients an unprecedented view into their portfolios, we need data -- from as many sources, vendors, and intermediaries as possible. Our market and portfolio data pipelines ingest benchmarks, security terms, accounting, and performance data from hundreds of integration partners. Behind this data pipeline is a database. And like every database, ours requires maintenance and care. Maintaining an obsolete database instance is challenging due to lack of support, inferior performance, and a dwindling developer community. As our dataset grew and we faced increased stability and performance requirements, the engineering group at Addepar decided it was time to upgrade our venerable Mongo 2.4 (TokuMX 2.0) database to the latest and greatest Mongo 3.4. Every organization has at least one database saga, and we're excited to share one of ours. Dependency management extends to databases Upgrading a database is a tricky business. Like other dependencies that support a product, databases have a tendency to fall out of date. Upgrades are deferred until that imagined future where everything is stable, clients have exhausted their feature request lists, and there's not much to do in the office other than play foosball and exchange memes. It's an understandable decision! Databases are complicated, leaky abstractions that inevitably form an implicit extension of our application logic. Their data types, atomicity guarantees, and transactionality semantics define the constraints we place on data and drive how we store application state. And because these guarantees (or lack thereof) tend to change (in ways that are sometimes undocumented!) between database versions, moving to the latest release is a risky proposition. Motivated by our need for an extremely reliable datastore that could handle complex and evolving schemas, we chose Mongo as the sole database for Addepar's ## A common data format DevFeed: [A common data format]() Original publisher: [Read original article]() Author: Dénes Findrik Published: 2017-10-17T13:11:10Z Content type: article Language: en Sources: [Addepar]() Topics: [data](), [Finance](), [Graphs](), [CSV](), [Transactions]() Tags: [csv](), [data](), [etl](), [finance](), [fintech](), [text](), [transactions]() ### AI overview The article explains how financial data arrives from many sources in inconsistent formats and proposes a simple common interchange format. It argues that separating shared accounting concepts from data-transformation processes can help standardize inputs to a Financial Graph and make the platform easier to build on and validate. ### Source excerpt Every day we parse financial data from hundreds of sources, including custodial banks, prime brokerages, fund administrators, private banks, and market data vendors. We receive data in a variety of formats: CSVs, TSVs, text files, custom formats -- and there are basically as many representations as sources. This variety of data formats is a side effect of Finance's long history with Tech: the industry has been a major force of innovation. Financial institutions have invested a lot to ensure that they have the technology they need to operate. As a result, competing complex systems are now used to represent the same data. Each different system introduces different constraints, and each constraint can have implications for how people think about the inner workings of the financial world. How can we push all this data into a consistent Financial Graph? The answer lies in defining a simple common format. The Problem Receiving data in a lot of different formats isn't necessarily a hard problem on its own: the greater challenge is handling the significant differences in how the same data is represented from source to source. To better illustrate this problem, let's take a very simple example. We have a single account that already has 100 shares of Alphabet and $15,000 cash. From that account, we buy 20 shares of Apple at $140 per share with a $50 broker fee for the transaction. The following are just a few hypothetical ways this same, simple set of transactions could be represented at the end of the day: Source 1 Positions.csv Date ,Account,Symbol,Name ,Quantity,CurrCode ,Type,Exchange 20170131,1234 ,GOOG ,Google Inc,100 ,USD ,STK ,NASDAQ 20170131,1234 ,USD ,US Dollars,12150 ,USD ,CRY , 20170131,1234 ,AAPL ,Apple Inc ,20 ,USD ,STK ,NASDAQ Transactions.csv Date ,Account,Quantity,Amount,Symbol,CurrencyCode,Type,SettleDate 20170131,1234 ,20 ,2800 ,AAPL ,USD ,BY ,20170131 20170131,1234 ,0 ,50 ,AAPL ,USD ,FEE ,20170131Source 2 Positions.txt Account Date Symbol Quantity 1234 2017