New Forge Technologies

Realized on Hacker News

2010-08-04T10:15:00-04:00

Today, I am inviting readers of Hacker News to sign up for Realized.

To start using Realized now, sign up at http://realized-app.com. If you have a few minutes, check out the product tour.

What is Realized?

Realized is a web app for investors who want to get higher returns by lowering their investment costs. And the biggest costs are not commissions or management fees, but rather capital gains tax.

If you are an individual investor or financial advisor, you may have already found it surprisingly difficult to manage your stock portfolio on the web. Most financial web sites are devoted to what might be called the buy side of investing. Financial analysts love to recommend stocks. Buying is easy and nearly cost free, with online brokerages and low commissions. Everybody has thousands of choices: stocks, ETFs and mutual funds.

The sell side is what generates the real costs

Almost no one provides guidance about when and what to sell from your portfolio. But selling is specific to only those securities that you already hold. Selling also generates taxable capital gains. Selling the wrong security at the wrong time can have a catastrophic effect on your rate of return.

Managing a portfolio well requires real discipline with regard to selling securities.

Forget about timing the market: focus on timing your portfolio

By netting out gains and losses, most investors can sharply lower their tax burden. Turning unrealized into actual losses allows for other sales to become literally tax free.

Most investment finance software concentrates on calculating capital gains tax at the end of the year. You find out where you stand after the fact. By that time, it may be too late to offset gains with losses. You are stuck with the capital gains tax that might have been avoided.

Realized aims to change things.

Individual investors and financial advisors need a tool that helps them avoid making trades that cost dearly. Realized does just that, making stock investing and capital gains tax simple and straightforward, year-round.

Launch of Realized-app

2010-07-30T11:45:00-04:00

Yesterday we launched Realized-app.com in a no cost, preview phase.

As previously mentioned, Realized-app began as a simple Ruby on Rails demonstration project. Quickly the proof of concept became a viable app, due mainly to the developer productivity that Rails provides.

For a preview of its capabilities, check out the product tour.

With nearly 60 models in this release, Realized-app represents a relatively modest Rails app. For those developers who would like to explore the app, you are welcome to sign up for free and try it.

Workflow for Realized-app support

2010-06-28T15:45:00-04:00

Squarespace has an extensive user manual. Beginning users can easily find a Getting Started section. A searchable set of how-to articles and FAQ answer questions from more experienced users.

When we explored alternative platforms for Realized-app support, we wanted to emulate Squarespace as a starting point. We anticipated that a typical need for support might pass through three stages:

Reading the manual
Searching the forums for similar issues
Asking a question via email

One aspect of Tender stood out from the other SaaS providers. It provides a searchable knowledge base to 'Help your customers help themselves'. After seeing that feature, other platforms seemed to be just combinations of forums and email managers.

Fancybox screenshots with jQuery

2010-05-08T12:30:00-04:00

In late April, we added screenshots to the Realized-app product tour. Our design drew upon an idea we saw at AgileZen.com, where clicking a thumbnail expands into a larger screenshot lightbox.

The Realized-app already makes use of jQuery, mainly for client-side processing of stock ticker choices. To animate our screenshots, we adopted the jQuery plugin that AgileZen uses, Fancybox. Our configuration:

$(document).ready(function() {
  $(".fancybox > a").fancybox({
    'hideOnContentClick':true,
    'titleShow':false,
    'transitionIn':'elastic',
    'transitionOut':'elastic',
    'speedIn':800,
    'speedOut':800,
    'easingIn':'easeInOutExpo',
    'easingOut':'easeInOutExpo'
    . . .

One interesting aspect of configuring Fancybox is its support of the Easing plugin to control the transitions. Easing controls how an animation progresses over time by varying its acceleration, giving each transition a more natural effect.

Remove functionality to improve usability

2010-03-10T10:00:00-05:00

The stock of ABC (AmerisourceBergen Corp) split 2 for 1 on June 15, 2009. The split doubled the number of shares that each of the thousands of ABC stockholders held. For those tracking their investments with Quicken, each would then need to enter a transaction to record the stock split.

Having each of our customers enter the same publicly available information about a stock split seems like a missed opportunity. If Realized-app stored the stock split once, then why should it ever need to be entered again?

Realized automatically applies stock splits

As an example, two investors have purchased ABC stock. The first bought 100 shares on March 1, 2009 (before the stock split). The second bought 200 shares last week. Today, each holds 200 shares.

How does the share quantity of the first investor get adjusted for the split? The Realized-app already stores stock split info. Rather than asking the first investor to record the stock split, the Realized-app applies the stock split to that holding during the tax lot setup process.

Better usability

Because a web app uses a common data store, it can share public information among individual accounts. By reusing the specifics about a stock split among all of our users, Realized-app has removed one source of redundant or erroneous data input. In effect, we have improved the usability by removing the functionality of recording a stock split.

Git workflow for a staging environment with Heroku and GitHub

2010-02-01T13:30:00-05:00

Having a staging environment to verify changes adds an extra measure of confidence to each deployment. Git is the primary means for deploying apps to Heroku. For Heroku, a staging environment corresponds to another app. For Git, it is just a branch.

Thomas Balthazar has written a full outline of how to deploy multiple environments on Heroku and still host your code on GitHub. With the Heroku and GitHub repos thus configured, our local repo has three branches:

Working
Staging
Production (master)

Why do we use Git?

We build and test all changes in the Working branch before merging with the Production master. Our workflow to deploy a tested change from Working through Staging to Production:

# standing in /rails_app_root
git checkout -b working
# after committing a change
git status
# nothing to commit (working directory clean)
git checkout staging
git merge working
# 'see' Fast forward
git push heroku_staging staging:master
heroku maintenance:off --app staging_app_name
# exercise the staging app to verify change
heroku maintenance:on --app staging_app_name
git push  # to GitHub
git checkout master
git merge staging
# 'see' Fast forward
heroku maintenance:on --app production_app_name
git push heroku_production
heroku maintenance:off --app production_app_name
git push  # to GitHub
git checkout working
# go forth and make more changes

Witness the ease with which a local Git repo operates with remotes on GitHub and Heroku. Those who have not yet tried Git may not know what they have been missing.

Beta testing started

2010-01-07T09:15:00-05:00

As announced on blog.realized-app.com, we started beta testing Realized-app via invitations in December.

For developers who want to check out a medium-scale Rails application before its public release, you are also welcome to test. Just go to www.realized-app.com/beta and mention 'open source' in the remarks section.

Background processing on Heroku

2009-12-04T11:00:00-05:00

Some months ago we adopted delayed_job as our asynchronous background processor. In Realized-app several tasks, particularly tax lot setup, benefit from background processing.

Taking the advice from this blog post on GitHub, we reduced the coupling between models and the message queue by placing the background methods in lib/msg_queue.rb.

module MsgQueue
  class UserActivationConfirm < Struct.new(:user_id)
    def perform
      user = User.find(user_id)
      user.activation_confirmation_email
    end
    . . .

We create the corresponding delayed job in models/user.rb.

class User
  def activation_confirmation_mq
    mq = MsgQueue::UserActivationConfirm.new(id)
    Delayed::Job.enqueue(mq)
  end
end

The call to Job#enqueue remains within each model to allow for passing a priority parameter, should that be needed.

Deployment on Heroku

Heroku began limited support for delayed_job in July. Yesterday Heroku broadened that support with a new feature that provides for multiple delayed_job workers per app. That capability sealed our decision to deploy, at least initially, on Heroku.

Unit testing ActiveRecord validations and PostgreSQL constraints

2009-11-16T14:45:00-05:00

Some of the more rudimentary aspects of unit testing involve validation. These tests may exercise ActiveRecord or the database constraints created by a migration.

In a chapter from Enterprise Rails, 'Database As a Fortress', author Dan Chak advocates for employing the data integrity features of modern databases, particularly PostgreSQL. With Realized-app, we use PostgreSQL as a persistent data store.

To go beyond just testing the ActiveRecord model validations, in testing a database constraint Dan suggests using the following test_helper.rb method:

def expect_db_error(&block)
  begin
    yield
  rescue ActiveRecord::StatementInvalid
    database_threw_error = true
  rescue
    something_else_threw_error = true
  end
  assert !something_else_threw_error, 'defective case'
  assert database_threw_error && !something_else_threw_error
end

One difficulty with testing database constraints is that the ActiveRecord model validations may catch some errors before they reach the PostgreSQL database. As a work-around, we can add another method:

def svf(obj) obj.save_with_validation(false) end

Using these test helpers, this test will properly exercise the database constraints defined by a migration.

test 'name too long' do
  expect_db_error { svf(some_model_save(:name => 'name_too_long')) }
end

Such validation tests tend to be similar among different models. Just as concerned_with allowed for division of model logic into discrete files, we place unit test validation tests in a separate /test/unit/validation directory. This prevents cluttering model-specific logic with boilerplate validation checks.

Using Objected Oriented CSS

2009-10-05T09:00:00-04:00

Most web apps can benefit by leveraging a CSS framework to follow best practices. Realized-app is no different.

Our chosen CSS framework, Object Oriented CSS stood out because of two underlying principles:

Separate structure and skin
Separate container and content

With Object Oriented CSS, columns or grids control width. Content controls height. Modules provide containers. Skins are applied to any of these structures.

Like Rails, the framework continues to evolve. Our adoption of Object Oriented CSS divides it into three parts:

Core
Core mods
Skins

The core consists of five .css files: libraries, template, grid, content and module. Rather than modifying the core, we place any modifications to the core in five core mods files. We then associate a distinct skin.css to each of the core elements. As the core files evolve, we simply replace them without disturbing the remaining files.

concerned_with readable rails models

2009-09-03T15:15:00-04:00

Several models within our web app, Realized-app, have grown to more than 500 lines. Rapidly grasping the relationships among methods in these models had become difficult. Some means of dividing the models into coherent pieces was needed.

An elegant fix came about while reading the code for the rails-based forum, altered_beast. First, app/models contains a 'user' directory. Near the top of models/user.rb, also note a call to concerned_with:

class User < ActiveRecord::Base
  concerned_with :validation, :states, :activation, :posting
  . . .

One of the rails initializers defines concerned_with. Four files named by the symbols passed to concerned_with reside in app/models/user. The user methods pertaining to validation are found in models/user/validation.rb. Without the separation provided by concerned_with, this validation logic would exist in models/user.rb.

Using concerned_with, we have refactored the largest models in Realized-app. Now, at a glance, most of the functionality unique to a particular model becomes readily apparent.

For a good perspective on the origin of concerned_with and how to use it, see this post by Paul Barry.

Startup ideas we'd like to fund

2009-07-26T23:30:00-04:00

A year ago, Paul Graham listed a few Startup Ideas We'd Like to Fund.

#21: "Finance software for individuals and small businesses. Intuit seems ripe for picking off. The difficulty is that they've got data connections with all the banks. That's hard for a small startup to match. But if you can start in a neighboring area and gradually expand into their territory, you could displace them."

We all watched as Mint entered that space. But both Quicken and Mint fall short when it comes to handling stock investments. Their data connections with financial institutions provide real convenience, but pose issues of security and privacy.

The web is full of personal finance sites with ideas about buying stock. Few address the problem of selling stock from a portfolio to minimize realized capital gains and maintain balanced diversification. And even fewer calculate capital gains and support the preparation of Schedule D.

To maintain privacy, rather than relying on a direct import from each broker, Realized-app uses the FasterCSV gem to import trade history from a .csv history file.

Realized-app began as a Ruby on Rails demonstration project. Time will tell whether security and privacy trump convenience.

Realized-app blog

2009-06-02T12:15:00-04:00

Last week we launched our product blog blog.realized-app.com.

Development of our web app, Realized-app, will require several more months before we begin beta testing. With blog.realized-app.com, we will focus on the investment issues faced by individual investors and financial advisors. Many of the underlying concepts of Realized-app came about because these issues have few solutions available online.

Using Jekyll to generate our blog

2009-05-11T08:45:00-04:00

Welcome to our blog. We have been working for nearly five months to create a simple and effective stock portfolio management tool.

Much of our energy this year has been devoted to building our web app, Realized-app. Taking a few hours to look into a blog architecture was a welcome change in direction. Very quickly we settled on Jekyll for use as a blog generator.

Jekyll is written in Ruby. Because of that, we are confident that if our needs outgrow Jekyll, we should be able to bolt something on without too much difficulty. One of its early proponents, Henrik Nyh did just that by adding support for Haml. Using Haml allowed us to streamline the design of our blog archive page.

Look for the launch of the Realized-app blog soon, also to be built on Jekyll.