iPhone activation hell
So I waltz in and out of the local Apple store last night with neat little iPhone bag in hand and I'm feeling pretty smug. Pure bliss.
Eighteen hours later (and counting) and some of the bliss has worn off. Like many, during my activation, I am told that my activation will take more time. How long? Doesn't really say, but I will be receiving an e-mail when my phone is ready to be activated. I'm switching my number from TMobile, which scattered reports have fingered as a potential source of trouble. After six calls, I finally got through to an AT&T service rep, who helpfully informs me that somehow my IMEI code was listed incorrectly in their system. Not sure how that can happen since it is supposed to be passed through automatically. Anyway, she re-requested the activation or something so now I'm supposed to wait 24-48 hours before checking in.
What a let down. I haven't used AT&T for cellular service before - I'm feeling like they might be the weak link in the chain.
Update:
So ten minutes after posting yesterday my hoped for email arrived and I was admitted into iPhone-land. The bliss is back. What an amazing product. Groundbreaking. Landmark. The apogee of industrial design for this young century. There are a bunch of ways it could be improved - faster network, IP phone calls, ability to run your own programs, but, all in all, it's the kind of product that makes you wonder how everyone else could have gotten it so wrong for so long. Wow.
Saturday, June 30, 2007
Friday, June 29, 2007
Volatility weirdness
You wouldn't know it by just looking at the VIX, but volatility was on the march today. While the VIX advanced a point to 16.5, equity option volatility was sharply higher across the market on the last day of the quarter. Much of that may be due to marking - i.e. position traders pushing around the bid/ask prices to get favorable closing marks for the quarter. However, there's also a definite whiff of sub-prime fear permeating the market, just like last Feb/Mar when we had the spectacular New Century Financial blow-out. Vol seems most elevated in financials, insurance, construction, etc., just like before. However, tech seems to have a significant spike as well - that may be due to the iPhone launch and what is says about the power of blockbuster products.
At some point, the market is likely to settle down into the summer doldrums. Also, there are only 3 1/2 trading days in the US next week (July 3rd is a half day). You would think that would bring vols back in a little. We shall see.
You wouldn't know it by just looking at the VIX, but volatility was on the march today. While the VIX advanced a point to 16.5, equity option volatility was sharply higher across the market on the last day of the quarter. Much of that may be due to marking - i.e. position traders pushing around the bid/ask prices to get favorable closing marks for the quarter. However, there's also a definite whiff of sub-prime fear permeating the market, just like last Feb/Mar when we had the spectacular New Century Financial blow-out. Vol seems most elevated in financials, insurance, construction, etc., just like before. However, tech seems to have a significant spike as well - that may be due to the iPhone launch and what is says about the power of blockbuster products.
At some point, the market is likely to settle down into the summer doldrums. Also, there are only 3 1/2 trading days in the US next week (July 3rd is a half day). You would think that would bring vols back in a little. We shall see.
What's "local time" on the web?
According to the Apple marketing machine, the iPhone will be available at 6pm "local time" today. However, what does that mean if you want to go online to buy one (or two)? According to a very helpful chat rep at the online store, that means 6pm PDT.
I guess we'll find out how well their web infrastructure was designed.
According to the Apple marketing machine, the iPhone will be available at 6pm "local time" today. However, what does that mean if you want to go online to buy one (or two)? According to a very helpful chat rep at the online store, that means 6pm PDT.
I guess we'll find out how well their web infrastructure was designed.
Thursday, June 28, 2007
Why is C++ so hard to read?
I spend the majority of my time staring at C# code. And because I value my time, I have always made a purpose to program in a style that is easy to read and decipher. I don't use abbreviations for class, method or member names. I always call things exactly what they are. I use the same patterns wherever I can, etc. Nothing any rational developer would think twice about before doing. And, conveniently, C# makes it easy: it uses a minimum of syntax, has sensible document formating and relatively easy mechanisms for navigating around complicated structures.
However, I got a reminder today about why I hate C++ so much. I spent most of the day going over my QuickFix based FIX engine. Don't get me wrong, I love QuickFix. It's fast, reliable, and best of all, the price is right. However, its core is written in unmanaged C++ and it is darn near impossible to figure out what's going on with it. It's almost as if the folks that developed C++ way back when decided that obfuscation was a programming best practice and made it as easy as possible for the programmer to achieve. There's so many darn ways to do the same thing in C++ and it seems like the average C++ developer just can't resist the invitation.
Why, for instance, do I have to always look in two places (the *.h file and the *.cpp file) to find where the developer might have hidden the particular function I'm looking for? What's the deal with all the different intermediate files and compilation target options? I don't care if it's a *.lib or a *.dll, I just want it to work. And don't get me started on compiler switches. I've spent too damn many days tearing my hair out trying to flip the right compiler switch to get someone else's framework to compile in my environment. Of course, C# has taken care of all of this nonsense. Working with someone else's code base is trivial. Just download the source, add the project to your own and bingo, there you go (well, as long as they haven't forgotten to remove any dependencies to their internal packages, which often happens, what are you gonna do?)
Any way, that's my rant for the night.
I spend the majority of my time staring at C# code. And because I value my time, I have always made a purpose to program in a style that is easy to read and decipher. I don't use abbreviations for class, method or member names. I always call things exactly what they are. I use the same patterns wherever I can, etc. Nothing any rational developer would think twice about before doing. And, conveniently, C# makes it easy: it uses a minimum of syntax, has sensible document formating and relatively easy mechanisms for navigating around complicated structures.
However, I got a reminder today about why I hate C++ so much. I spent most of the day going over my QuickFix based FIX engine. Don't get me wrong, I love QuickFix. It's fast, reliable, and best of all, the price is right. However, its core is written in unmanaged C++ and it is darn near impossible to figure out what's going on with it. It's almost as if the folks that developed C++ way back when decided that obfuscation was a programming best practice and made it as easy as possible for the programmer to achieve. There's so many darn ways to do the same thing in C++ and it seems like the average C++ developer just can't resist the invitation.
Why, for instance, do I have to always look in two places (the *.h file and the *.cpp file) to find where the developer might have hidden the particular function I'm looking for? What's the deal with all the different intermediate files and compilation target options? I don't care if it's a *.lib or a *.dll, I just want it to work. And don't get me started on compiler switches. I've spent too damn many days tearing my hair out trying to flip the right compiler switch to get someone else's framework to compile in my environment. Of course, C# has taken care of all of this nonsense. Working with someone else's code base is trivial. Just download the source, add the project to your own and bingo, there you go (well, as long as they haven't forgotten to remove any dependencies to their internal packages, which often happens, what are you gonna do?)
Any way, that's my rant for the night.
Wednesday, June 27, 2007
So what is Volatility Arbitrage anyway?
Vol arb, as described here, is a type of quantitative trading in which bets are placed on the difference between an option's current market (implied) volatility, and a trader's best guess of how much actual volatility of the option's underlier realizes over the duration of the option. It's somewhat complicated, but it essentially boils down to buying and selling insurance on stocks, or whatever the option's underlier happens to be.
Vol arb is what I do. Well, at least it's what the tools and systems I build are designed to do. Without going into specifics, vol arb requires a lot of system support. Option prices move quickly, risks are many and not always easy to understand, and the market is very, very sophisticated. A nice fat juicy berry can turn into a lemon in a split second. And if you spend too long on your homework to make sure it really is a berry, odds are someone will come along and scoop it out from under you. Tools to support vol arb trading have to be fast, accurate and reliable. They need to display lots of data quickly, with minimal latency. When systems crash, or fail to provide accurate calculations, risks can grow exponentially.
In my previous post, I made the claim that .NET and C# are the best overall development environment for meeting this challenge. Particularly when development resources are tight. I believe this is true because of the design philosophy behind C#. Consistent, highly quality, high security, object-oriented features built upon decades of best practices in designing computer languages. Across every dimension I care about, I consistently find well thought-out, well implemented functionality. Code compiles cleanly to near bare metal speed, threading interfaces are easy to understand and work as expected, distributed computing and remote objects are almost second nature, and, of course, tight integration with high-quality, 3rd party screen components that run natively on the Windows operating system (still the best bang for the buck for high-performance processing anywhere). Some have called C# buggy. I beg to differ. In the entire time I have spent building out my framework, not once have I encountered a bug that I could trace back to C# or the CLR (there were a couple of minor annoyances with Visual Studio 2005 when it first came out, but rapid and intelligent support from Microsoft cracked these quickly).
Taken together, no other development language can match of these features. As I mentioned in my earlier post, some processes may require pure bare metal - like you can get with C, such as for pricing models. Some parts of market data feed handlers are also well-suited to C, particularly when you are trying to capture up to 200k+ updates per second, as you can see on the OPRA feed. However, these areas tend to be isolated, and because of their nature, should have employ a bare minimum of code. Once outside of these high-demand areas, i.e. the vast majority of the code in an enterprise system such as you need to support vol arb trading, C# enters it's forte.
Vol arb, as described here, is a type of quantitative trading in which bets are placed on the difference between an option's current market (implied) volatility, and a trader's best guess of how much actual volatility of the option's underlier realizes over the duration of the option. It's somewhat complicated, but it essentially boils down to buying and selling insurance on stocks, or whatever the option's underlier happens to be.
Vol arb is what I do. Well, at least it's what the tools and systems I build are designed to do. Without going into specifics, vol arb requires a lot of system support. Option prices move quickly, risks are many and not always easy to understand, and the market is very, very sophisticated. A nice fat juicy berry can turn into a lemon in a split second. And if you spend too long on your homework to make sure it really is a berry, odds are someone will come along and scoop it out from under you. Tools to support vol arb trading have to be fast, accurate and reliable. They need to display lots of data quickly, with minimal latency. When systems crash, or fail to provide accurate calculations, risks can grow exponentially.
In my previous post, I made the claim that .NET and C# are the best overall development environment for meeting this challenge. Particularly when development resources are tight. I believe this is true because of the design philosophy behind C#. Consistent, highly quality, high security, object-oriented features built upon decades of best practices in designing computer languages. Across every dimension I care about, I consistently find well thought-out, well implemented functionality. Code compiles cleanly to near bare metal speed, threading interfaces are easy to understand and work as expected, distributed computing and remote objects are almost second nature, and, of course, tight integration with high-quality, 3rd party screen components that run natively on the Windows operating system (still the best bang for the buck for high-performance processing anywhere). Some have called C# buggy. I beg to differ. In the entire time I have spent building out my framework, not once have I encountered a bug that I could trace back to C# or the CLR (there were a couple of minor annoyances with Visual Studio 2005 when it first came out, but rapid and intelligent support from Microsoft cracked these quickly).
Taken together, no other development language can match of these features. As I mentioned in my earlier post, some processes may require pure bare metal - like you can get with C, such as for pricing models. Some parts of market data feed handlers are also well-suited to C, particularly when you are trying to capture up to 200k+ updates per second, as you can see on the OPRA feed. However, these areas tend to be isolated, and because of their nature, should have employ a bare minimum of code. Once outside of these high-demand areas, i.e. the vast majority of the code in an enterprise system such as you need to support vol arb trading, C# enters it's forte.
Tuesday, June 26, 2007
Trading Options with C#
As a financial technology professional of many years, I have witnessed far more technology battles than I would care to remember. C, C++, Objective-C, Smalltalk, Java, Visual Basic, Perl, Python, Tcl, SQL, XML, Windows, NextStep, SunOS, Linux. . . there was always someone ready to champion the next great technology platform, especially if it was different from what was already being used by the majority of the development staff. Unless, of course, they happened to be a lead architect/development manager/CTO who actually chose the current development platform. In that case, use of any other platform was considered heresy and punishable by whatever forms of torture was most readily at hand.
Now, however, I have left the technologies wars behind. I have ventured out on my own in a startup, greenfield trading group. As the sole member of our IT team, I find it remarkably easy to dictate the terms on which the tech battles will be waged. In fact, the tech battles seem to be somewhat placid. If something appeals to me and I can justify the expense of my limited time, it happens. All the implements of torture lie unused.
I am now planning to write down some of the experiences I have had to get where I am. Hopefully some will find this of interest. Some may even choose to comment, or even to ridicule. My only hope is that I can expand the somewhat insular world of high-frequency trading.
First of all, I would like to make an assertion. Microsoft's .NET framework, and C# in particular, is without doubt the best development framework ever devised for building high-frequency trading applications where latency and reliability are at issue. I can confidently say that I would be nowhere near where I am today (powering the tools for a small but somewhat successful quantitative hedge fund) if I had started in another language. I'm sure there are plenty of screens out there on which the spittle has just landed. Graeme at Enhyper, for instance, may not agree with me. However, I can say from direct experience that C# and .NET should inspire confidence when chosen for hard, high-performance tasks. (I tried to engage Graeme at his site, but comments are 'moderated' and my attempts to post a response there have so far been unsuccessful.)
I am not a purist. I certainly believe that the extra 30% or so of performance you can get from raw C can be worth it in a limited number of bottleneck areas. For instance, when writing an option pricing model, C is probably a good choice. However, for the bulk of the framework - user tools, processing engines, persistence management, object life-cycle, messaging, etc, the stuff that makes up 95% of your actual coding, C# can't be beat. Full stop.
I'll have more to say later, but I just had to get this one of my chest.
As a financial technology professional of many years, I have witnessed far more technology battles than I would care to remember. C, C++, Objective-C, Smalltalk, Java, Visual Basic, Perl, Python, Tcl, SQL, XML, Windows, NextStep, SunOS, Linux. . . there was always someone ready to champion the next great technology platform, especially if it was different from what was already being used by the majority of the development staff. Unless, of course, they happened to be a lead architect/development manager/CTO who actually chose the current development platform. In that case, use of any other platform was considered heresy and punishable by whatever forms of torture was most readily at hand.
Now, however, I have left the technologies wars behind. I have ventured out on my own in a startup, greenfield trading group. As the sole member of our IT team, I find it remarkably easy to dictate the terms on which the tech battles will be waged. In fact, the tech battles seem to be somewhat placid. If something appeals to me and I can justify the expense of my limited time, it happens. All the implements of torture lie unused.
I am now planning to write down some of the experiences I have had to get where I am. Hopefully some will find this of interest. Some may even choose to comment, or even to ridicule. My only hope is that I can expand the somewhat insular world of high-frequency trading.
First of all, I would like to make an assertion. Microsoft's .NET framework, and C# in particular, is without doubt the best development framework ever devised for building high-frequency trading applications where latency and reliability are at issue. I can confidently say that I would be nowhere near where I am today (powering the tools for a small but somewhat successful quantitative hedge fund) if I had started in another language. I'm sure there are plenty of screens out there on which the spittle has just landed. Graeme at Enhyper, for instance, may not agree with me. However, I can say from direct experience that C# and .NET should inspire confidence when chosen for hard, high-performance tasks. (I tried to engage Graeme at his site, but comments are 'moderated' and my attempts to post a response there have so far been unsuccessful.)
I am not a purist. I certainly believe that the extra 30% or so of performance you can get from raw C can be worth it in a limited number of bottleneck areas. For instance, when writing an option pricing model, C is probably a good choice. However, for the bulk of the framework - user tools, processing engines, persistence management, object life-cycle, messaging, etc, the stuff that makes up 95% of your actual coding, C# can't be beat. Full stop.
I'll have more to say later, but I just had to get this one of my chest.
Subscribe to:
Posts (Atom)