Investment Tracking with Fidelity

It’s easier to invest money than ever before. You can invest in companies around the globe with just a phone call or a few clicks of your mouse. You can put your money in a seemingly infinite number of vehicles for those same companies, such as mutual funds (which contain a selection of companies in the same stock) or index funds (which mirror the movement of entire industries’ worth of stock). You can even invest in extremely complicated derivatives, which are related to the underlying stock (or, for that matter, other security) and minimize risk for one party while increasing the potential reward for the other.

Along with the increased number of investment options, the pace of the economy continues to get faster. So, it becomes harder and harder to keep up with the status of all of your current and future investments. Yet, you need to be able to take rapid action to respond to changing marketplace conditions, which means you want to be able to follow those changing conditions quickly and easily.

Of course, you can keep track of the marketplace using traditional tools—like the newspaper and television reports—as well as through investment sites like Yahoo! Finance or various online stock brokerage sites. However, if you want to accomplish a specific, custom reporting goal, you need to write some custom code. This chapter’s example demonstrates how to create such a report, tracking investments with Fidelity Investments (http://www.fidelity.com).

Writing a Small Server to Get Report Data

For this chapter’s example, you will create a small web server to feed data to your reporting system. This approach can be useful in several situations.  

For example, if you have mixed Linux and Windows servers, often you’ll find that some tasks, such as controlling Component Object Model (COM) objects or communicating with a Microsoft SQL Server, are better performed directly on the Windows system. (COM is a way for Windows applications to access the software components of other Windows applications.)

To handle these tasks, you can often write a tiny server that uses proprietary extensions directly on the Windows server and then serve it up in an open, easy-to-use format, such as XML. This lets the work of accessing proprietary Windows libraries stay on the Windows machine, so you don’t need to use potentially buggy open source drivers designed to access proprietary code. (Of course, some open source drivers designed to access proprietary code are very good, and in those cases, you might not need an intermediary.)

Tip  At times, the opposite approach works well. For example, you could write an XML feed on your Linux server that is read by a client-side Windows application, which then uses COM to automatically open Microsoft Word or Microsoft Access to insert the data. This way, you don’t need to generate Word or Access documents by hand, which is problematic when it’s even possible at all. You get the entire benefit of Microsoft Office without writing any custom Word or Access output code, and your clients get data in a familiar format that they can manipulate.

Mongrel is a popular web server that works with Ruby. Mongrel is typically used to serve Rails applications, but it can also be used to host small web servers directly. You can find more information about Mongrel at http://mongrel.rubyforge.org/rdoc/files/README.html.You’ll use Mongrel as a simple XML server in this chapter’s example.

Of course, you could write a Rails application to serve XML data. But for a simple server, such as one that has only a single URL, that might be overkill. Consider that an empty Rails application on my FreeBSD machine uses 3MB of memory, and, in my experience, Rails applications of any complexity rarely use less than 10MB of memory per process (and often more).

For example, if you need a chat server with one connection per user, and you’re using a Rails application consuming 10MB or more of memory per user, that memory consumption can add up very quickly. If you have hundreds of users, that becomes a very serious problem. Alternatively, you can often handle your chat connection with a simple server. Using a server like Mongrel will be much faster than using a full-featured Rails server, and you’ll be able to serve more clients in the given amount of memory.

Of course, Rails takes up memory for a reason: it does numerous great things for you automatically. So if you need features such as sessions or complex templating, you’re probably better off creating a Rails application.

Nonetheless, for conceptually simple and lightweight purposes, writing a small Mongrel web server is a great way to make your application have less code, take less memory, and run faster.