jmjatlanta.com

There are plenty of reasons that I have been writing software since the age of 11 (Holy cow, how long ago was that? I feel old.). One of them is the pride that comes from conquering a hard-to-find bug. It feels so good to go through the process, knowing that the product will be improved once the cycle is complete.

There is not (and in my opinion should not be) a standardized process for squashing bugs. However, here are some of my guidelines.

For my own education, I am looking at the performance of TCP sockets. The goals of this project are:

There are a large number of people working long hours and spending employers' money on expensive hardware. Their goal is to make small brief financial trades with the net result providing a fraction of a penny profit.

Why do their employers devote those resources? Partly because it is profitable. But also because without the investment, they may be put out of business.

So what are these companies doing to stay competitive? The answer is tightly locked in their developer's areas.

Being a contract software engineer has plenty of challenges. I'm not going to talk about the typical "entrepreneur" problems. Instead I am going to focus on the ones I've seen that are specific to software engineering and also are of recent vintage.

I do not practice the Hindu nor Buddhist religion. But the word Nirvana has an interesting history and connotation. Take a look on Wikipedia.

In the secular world, finding work that you enjoy doing can give you a taste of the good life. I do like what I do. That makes me very fortunate. It also keeps me very busy.

Now I am in my element. The more I dig into the networking elements, the closer I get to the hardware. Okay, so I am not a hardware guy. But I do like to be close to it. I think I should have been a driver developer. What? The salary is how much? Oh. Okay. Never mind.

In continuing with my TWS/FIX implementation, I've run into a snag with the way sockets are done between quickfix and the TWS api. So I'm digging through the Linux socket implementation to see how to best implement a fix.

This is another case where small non-complex applications can be built to learn the ins and outs of threads, sockets and ports. Removing the complexity of an entire application clears the head, so as to focus on the problem at hand.

The past few coding sessions have seen plenty of progress on my TWS / FIX project. While it still has plenty of code cleanup to go, decisions on the project layout need some forethought.

One of the biggest considerations on how the project should be laid out is due to the reliance on other projects. This project uses quickfix and the Interactive Brokers API. The source for each is readily available, but should not be included in the project when distributed.

Interactive Brokers has a nice API to communicate with their Trader Workstation in several languages. I am moving forward with an attempt to combine the TWS API with quickfix.

Yes, I know Interactive Brokers provides a FIX back end already. But this project does a number of things for me.

More info on its way...

I'm having fun learning quickfix. So far, I have built a middleware piece that sits between TWS and a client. The client can communicate via FIX and get a quote from TWS.

What?! No cheers from the crowd? I didn't think so. But what is happening is I am learning the ins and outs of the FIX protocol in pretty good detail. Once I finalize some basic functionality I'll throw it into a github or sourceforge project. More news as it happens...