This is a Keysight 1GHZ MSOX3104T. Brand new, never been turned on. Just arrived from the distributor.
I see one sold on eBay for $6300 recently. Make me an offer. I’d like to sell it locally (Alpharetta, GA).
See Pics below:
I am working on a “Trade Book” type algorithm that needs to be very robust, yet work within the constraints of commodity hardware. Let’s see what we can do with these specs:
These are tall orders to be sure. The first orders of business will be around selecting the tooling, testing frameworks, and gathering some metrics.
It’s been ages since I messed with (or even thought about) 2PC logic. Nostalgia and cobwebs.
On the surface, building an automated trading system seems like a great idea. Who wouldn’t want a machine that you turn on and generate profits?
Such systems do exist. And often the actual buy/sell/hold algorithm is not very complicated. But before you buy or build your personal ATM, there is much work to be done.
You have what you believe to be a winning strategy. You have back tested and even forward tested it. Now you want to put it into production. Congratulations, you have done more work than many. But there is still work to be done on your strategy.
The simple fact is that you, your strategy, and your broker perform differently when real money is involved. Here are some things that you should consider beyond your strategy.
Who will be responsible for placing the orders? Do you plan to use your own PC, or is the strategy hosted by someone else? Perhaps your broker hosts the strategy. Who is culpable when things go awry? What is the procedure when such events inevitably happen?
Did you consider the costs of your strategy? Are you assuming that a “market order” is going to give you something between the bid and ask? This is not always the case.
Does your strategy consider rebates or costs savings by switching venues?
Even if the network is alive and your order is accepted, that doesn’t mean things continue to go smoothly. Did you plan for what to do with partial fills? What should be done with orders canceled by your broker, or by the exchange itself?
Your order is filled. Now what?
Normally, you let your system continue to function. Perhaps the stop loss and take profit orders are in place waiting for one of your limits. Will they be there if the network goes down? What happens if the exchange has one of their famous glitches?
And then there is your emotions. What if the trade goes beyond what you feel comfortable with? What if new information comes to light, and you decide to close the position? Your system must respond accordingly.
Buying Power Issues
Brokers have risk systems that protect them from you. And often, their “paper trading” or test system will not include this. Will your system cause you to bump into their risk rules? Additionally, shouldn’t your system include code to measure risk?
We have just moved to a rented home near David, Panama. Our home has a yard with a variety of trees, many of which are fruit-bearing. An interesting one is “Mamon Chino”. In Asian countries it is called Rambutan.
You can learn more about this fruit at:
This picture is of fruit we just picked a few minutes ago. Mamon Chino is the red spiny-looking fruit on the left. The pit in the middle is covered in a gummy coating that is eaten.
I recently built a proof-of-concept to tackle controlling speakers using the Windows MultiMedia API. It turned out to be a fun little adjustment to some code I found on Stack Overflow by Brian Gradin.
I posted my results up on Github. I do not have a way of getting in contact with Brian, so am unsure how it should be licensed. Brian, if you’re reading this, hit me up.
The previous post talked about the Immutable pattern. This one is a slight variant.
A Freezable object can be adjusted until it is frozen. Once frozen, it behaves like an Immutable object. Such a pattern is handy for setting up objects that should not be modified once a certain point is reached, but that point cannot occur during initialization (i.e. within the constructor).
Some of the same headaches of the Immutable pattern exist with this pattern as well. I mention it because it works around one problem of the Immutable pattern.
While care needs to be taken before freezing, locking is not necessary afterward, as the data will not (or at least should not) be changing.
I wanted to create a series of posts on multithreaded design patterns. I will attempt to link them together so you can flip between them.
Click here for the Freezable pattern.
This is one of the easiest to implement. This simply prevents changes to the object once the object has been created. Methods and properties of this object are read-only, and no method calls can modify internal data.
If changes to values are required, a new object must be made.
For lightweight, uncomplicated objects, this may work well. This also works for objects that are created once and are needed to be read from many times.
The only risk here is multiple threads attempting to create a “singleton” that should be used by multiple threads. Think of multiple threads attempting to instantiate a “lazy loaded” configuration file. Both threads see it does not yet exist, both attempt to create it, and both then attempt to make it global (setting it to the same global variable).
Believe it or not, until recent changes, there was no portable way to fix this. The original problem is discussed >here<.
The answer relies on C++ 11 features. A discussion of options can be found >here<.
The largest percentage (by a large margin) of time spent by a software developer is maintaining existing code. A significant (although smaller) percentage will be in code that the same person recently wrote.
As the code base matures, there will be sections of code that the developer does not see for a long enough period of time that details will be forgotten. How quickly will he get up-to-speed on what that code does? More importantly, what is the best way to modify that code to match the new requirements?
This is where a strong programmer pays dividends. While many still do not believe this, clean code, documentation, and tests that exercise the code pay for themselves. Often, by the time a small section of code is complete, the extra time spent doing it right has already been paid back.
Hacking code together works. Placing code where it does not belong will get the task complete. All developers know this. And when you’re only doing a small contract, you’ll be gone before anyone notices the stench floating out of the code base.
Mature developers do not do such things. Not that they refuse to do things quickly. They simply know where to put things, how to make it clean, and make tests to satisfy themselves that the code works the way they want it to. The cost: $0
Developers: Learn to do things the right way. Your desire to do so will be repaid. Strive for quality code that is comprehensible (easy to read) and predictable (easily tested).
Clients: What you see as the final product may work, but modifications may prove costly. Spend a little time up-front thinking of how to find the right person for the job.
Yesterday Forbes.com brought to my attention an interesting article. Well written and I agree with many of the conclusions of the author.
Here’s the link…
I was in need of some quick code to get the dimensions of a JPEG. I happened upon this post that inspired me to write my own. I’ll post the results on GitHub (now posted here) when I get a chance, but some fun things came out of such research.